Uganda It Policy

8/2/2019 Uganda It Policy

http://slidepdf.com/reader/full/uganda-it-policy 1/66



1. Uganda has achieved strong economic growth and macroeconomic stability in the last decade, owing largely

to the implementation since the late1980s of an ambitious program of macroeconomic adjustment and

structural reform. The strong growth has been accompanied by a reduction in the proportion of Ugandans

living in absolute poverty. Despite the reduction in head count poverty, Uganda remains one of the poorest

countries in the world. Moreover, the distribution of welfare gains has varied across regions, sectors, andsocial/economic groups. As noted in the Poverty Eradication Action Plan (PEAP), the government is aware

that although economic growth is essential to reducing poverty, it is crucial to put the right policy framework

in place to ensure that all citizens, particularly the poorest members of the community, benefit from economic

growth. The government is therefore taking advantage of debt relief under the Heavily Indebted Poor

Countries (HIPC) Initiative, along with other forms of donor support, to increase public expenditures on

growth-oriented and antipoverty programs and accelerate the implementation of the PEAP. High economic

growth and poverty eradication, in the context of continued macroeconomic stability underpinned by

appropriate fiscal, monetary, and structural policies, will continue to be the government's principal economic

and social objectives. This document outlines the government's policies and strategies for the three-year period

1999/2000 – 2001/02 (July – June) and their impact on poverty reduction.

Contents

II. Background

2. Uganda has achieved strong, broad-based economic growth, with low inflation and an improved balance of

payments, through the implementation of a wide range of important macroeconomic policies and structural

reforms. Moreover, the improvement in the underlying fiscal situation, as well as increased donor assistance,

has facilitated a reduction of bank financing of the government deficit and adequate provision of credit to a

growing private sector. During the period 1994/95 – 1998/99, annual real GDP growth averaged 7.4 percent,

and the overall fiscal and current account deficits (excluding grants) averaged 6.9 percent and 7.8 percent,

respectively. By 1998/99, the rate of consumer price inflation had been brought down to 5 percent a year.

3. In 1997, the government launched the PEAP, which has in recent years gained substantial momentum,

building upon recent successes and rectifying problems. The PEAP sets forth the objective of reducing the

incidence of poverty to 10 percent by 2017. In recent years, the incidence of poverty fell from 56 percent of the

population in 1992/93 to 44 percent in 1996/97,1 owing primarily to strong economic growth, particularly in

the cash crop sector. Poverty fell across all income groups, regions, and districts. Nevertheless, despite these

encouraging trends, poverty remains endemic in Uganda. While strong economic growth is a major force in

reducing poverty, it is not sufficient to ensure that all segments in society benefit fully. In this regard, the

decline in poverty has been far more pronounced in urban than in the rural areas where the poor are

http://www.imf.org/external/np/pfp/1999/uganda/#top


http://www.imf.org/external/np/pfp/1999/uganda/#1







concentrated. Poverty remains more severe in the northern and the eastern regions. Several factors account for

the current disparities in the incidence of regional poverty, including insecurity, climate, type of agricultural

activity, and access to markets, inputs, and credit. Among sectors, people engaged in cash crop farming,

manufacturing, public utilities, and transport and communications have experienced the largest improvement

in living standards. However, those engaged in food crop production, a majority of whom are women, have notwitnessed a significant improvement in living conditions. Despite the impressive overall economic growth, the

incidence of poverty among the poorest 10 percent of the population increased in some years.2 Finally,

insecurity, vulnerability to external shocks (such as drought or unexpected illness), and erosion of traditional

networks of support continue to prevent the poor from living long, healthy lives. In particular, the prevalence

of HIV/AIDS has further weakened traditional networks of support and has contributed to a worsening in the

conditions of the poor.

4. The government has continued its three-pronged approach to reducing poverty by taking actions to (i)

increase incomes of the poor households, (ii) improve the quality of life of the poor, and (iii) reestablish

peaceful conditions throughout the country and strengthen governance structures. The first approach focuses

on income-augmenting activities — roads, land, agriculture, rural markets, employment and labor productivity,

and rural financial services. The second targets the provision of basic social services — primary health care,

education, water and environmental sanitation, and disaster management. The third element stresses actions to

improve security and reforms of state and government organs to strengthen transparency and accountability. In

this context, outlays on Priority Program Areas (PPAs), which incorporate the core antipoverty components of

expenditures on health, education, infrastructure, agriculture, and public institutions, increased by 60 percent in

nominal terms in 1998/99 and accounted for 20 percent of domestic nondebt expenditures, up from 15 percenta year earlier. Moreover, in 1998/99 the government established the Poverty Action Fund (PAF) to enhance the

monitoring of the use and impact of donor funds targeted for specific PEAP programs.

5. The PEAP evolved in the context of a participatory process that involved local communities, civil society,

the donor community, and the government. In this connection, in November 1995, the government of Uganda

held, in partnership with the World Bank, a seminar on poverty eradication, attended by representatives from

the government, nongovernmental organizations (NGOs), and the donor community. As a follow-up to the

seminar, the government established the National Task Force on Poverty Eradication, which developed an

action plan in consultation with sector ministries, donors, and civil society to ensure the widest possible

participation. This work culminated in the government's announcement in June 1997 of its PEAP.

6. In addition, NGOs participate actively in the review of programs and projects to be included in the annual

PAF budget, while select NGOs and donors are invited to take part in the working groups, which are

responsible for the development of sector spending projects. Moreover, district councils are envisaged to play







an important role in the selection of projects included in district budgets. Meanwhile, the pace of

implementation of projects funded under the PAF is monitored on a quarterly basis by a committee comprising

parliamentarians, donors, select NGOs, the media, and the government.

7. In the period ahead, Uganda still faces many challenges. While important initial steps have been taken to

implement a broad-based poverty reduction program, indications are that recent actions, as well as the high

economic growth rates achieved, have not consistently improved the well-being of the poorest 20 percent of

the population. Moreover, the differences in the incidence of poverty among the regions and between the rural

and urban areas remain large. In addition, the role of the budget as a poverty reduction instrument needs to be

strengthened through closer alignment of the central and district budget systems, greater involvement of local

communities in the development and selection of projects and programs, and improved monitoring of

operations. Furthermore, sustaining high economic growth will require a deepening of structural reform,

particularly in the financial and parastatal sectors, and a building up of an effective public service delivery

system, particularly at the district level. There is also a need to develop and regularly update a comprehensive

database for planning and poverty-monitoring purposes for all districts.

Contents

III. Objectives, Strategy, and Policies for 1999/2000 – 2001/02

A. Overview of the Three-Year Program

8. The principal objective of the government is, as set forth in the PEAP, to reduce poverty. Attainment of this

goal will require sustained high economic growth in a context of macroeconomic stability. Accordingly, the

government is determined to implement sound financial policies and structural and institutional reforms to

support high, broad-based economic growth and improve the quality of public services. In this regard, the

overall medium-term macroeconomic objectives that were set forth in the last policy framework paper (PFP)

remain appropriate: annual real GDP growth of 7 percent, annual inflation of about 5 percent, and gross

international reserves equivalent to about five months of imports of goods and services.

9. Achievement of the government's objectives will also require continuing prudent monetary and fiscal

policies, increasing expenditures on growth-oriented and social programs, and strengthening structural reformsto promote higher private sector investment and improve the delivery of public services. Regarding private

sector investment, a recent survey of firms in Uganda found that the constraints faced by firms include poor

quality of utility services, corruption, deficiencies in tax administration, weaknesses in the legal system, and

lack of long-term finance. In the 1999 Uganda Participatory Poverty Assessment (UPPA),3 poor communities

identified the following priority areas: improving security and access to clean water, eliminating corruption,










overcoming lack of information about, and access to, markets, upgrading road and transport systems,

improving access to family planning services, and improving nutritional levels.4 Actions and strategies to

tackle the constraints to private investment and address poverty issues are embedded in the government's

sector-specific policies contained in this paper.

B. Macroeconomic Policies, Structural Reforms, and Poverty Reduction

Fiscal policies

10. The government's medium-term fiscal program is geared toward sustaining financial stability and high

rates of economic growth, as well as supporting the PEAP. Accordingly, against the background of the present

financial environment — in particular, the success in achieving low and stable inflation, an adequate level of

foreign reserves, and a relatively favorable outlook for the balance of payments — and in conjunction with the

increased availability of donor support earmarked for social and priority sectors — the government considers it

important not to miss the opportunity to finance its social program through fiscal deficits somewhat larger than

the earlier PFP targets. As previously mentioned, public expenditures will focus on (i) increasing the incomes

of the poor through the provision of roads and support for the modernization of agriculture; (ii) improving the

quality of life for the poor through increased provision of health, education, and water services; and (iii)

strengthen-ing good governance through transparency and accountability. Nonwage recurrent expendi-tures on

PPAs (including development expenditures under the Universal Primary Education (UPE) program) are

budgeted to increase from 2.3 percent of GDP in 1998/99 to 2.7 percent in 1999/2000, and 2.9 percent in

2001/02. The government is committed to containing defense expenditures at 2.0 percent of GDP throughout

the three-year period and recognizes that any overruns in this area could endanger its antipoverty expenditure

program. Total expenditures are projected, on the basis of current donor commitments, to increase by about 2.1

percent of GDP to 20.6 percent of GDP in 1999/2000, and then decline gradually to 19.8 percent of GDP in

2001/02. The fiscal deficit would rise initially to 8.1 percent of GDP and decline gradually to 6.4 percent of

GDP in 2002 — this would entail a decline in development outlays. The projected figures do not take into

account any possible additional support under the enhanced HIPC Initiative, which would likely result in

higher public expenditures on social programs and larger fiscal deficits than are presently envisaged.

11. Revenue enhancement is a key element of fiscal sustainability. As the government does not foresee any

major change in tax rates, the envisaged increase in the revenue-to-GDP ratio of about 0.5 percentage of GDPa year is expected to stem primarily from improvement in tax and customs administration, enhanced tax

compliance, and a committed effort to combat fraud and smuggling. Beyond the policies for 1999/2000, which

are described in the memorandum of economic and financial policies (MEFP), the Uganda Revenue Authority

(URA) will introduce a new information technology that will integrate the different computer systems used by

its departments, continue its customs modernization efforts, extend direct banking procedures to domestic







excise and withholding taxes, intensify training programs, and establish a performance monitoring system in

all departments.

12. Expenditure monitoring and control will be strengthened at both the central and district government levels.

In this regard, domestic development outlays will be brought under the Commitment Control System (CCS) by

July 2000, at the latest. The medium-term budget framework also incorporates the elimination of all currently

identified domestic arrears by June 2002. Consistent with the objectives of shifting the delivery of most public

services to the districts, the government will transfer an increasing volume of budgetary resources to districts,

enhance their capacity to provide services effectively, and monitor their physical and financial operations.

Local government capacities for planning, budgeting, and monitoring are being enhanced under the Local

Government Development Program with donor support. In addition, PEAP projects financed through the

Poverty Action Fund are subject to quarterly reviews by the government, donors, and NGOs.5 The PAF also

provides resources to develop local government capacities to implement and monitor programs.

13. Full implementation of an effective anticorruption strategy will be essential to the realization of the poverty

reduction objective. Corruption impedes the effective delivery of public services to the poor and has been

identified by firms as a constraint on private sector investment. Good governance and the rule of law are

crucial to enhance accountability and transparency in government operations and to boost private sector

confidence. The government recognizes the need to enhance the integrity and accountability of its institutions

by (i) increasing public oversight through increased transparency, education and awareness; (ii) promoting

capacity building; and (iii) strengthening enforcement of laws and penalties. To this end, the government is

preparing an overall strategic framework to guide its actions in the governance area. In the meantime, the

government is strengthening existing anticorruption institutions (the Inspector General of Government, Auditor

General, and Department of Public Prosecution), in part through the provision of additional budgetary

resources, and will intensify investigations into suspected fraud and apply stricter penalties on all government

officials misusing public funds. The government will also submit to parliament amendments for an improved

Leadership Code and implement changes in public procurement procedures. In addition, the government will

disseminate audited accounts of the budgets of the central and district governments and other economic and

social statistics in a more timely fashion.

Monetary and financial sector policies

14. Monetary policy will continue to aim at maintaining low and stable inflation. To this end, the Bank of

Uganda (BOU) will continue to conduct monetary policy through the implementation of a reserve money

program, taking into account a broad array of financial indicators. Low and stable inflation will contribute to

poverty reduction by encouraging long-term domestic investment and attracting foreign direct investment on

assurance that the viability of investment would not be jeopardized by macroeconomic instability. Moreover,







low inflation would also help to prevent a deterioration of living standards by preserving the real value of

wages and assets. The main near-term challenge of monetary policy will be the management of the liquidity

impacts of recent bank closures and restructuring. Other challenges include managing the excess liquidity of

commercial banks and reacting to flows emanating from the functioning of a fully liberalized capital account.

The BOU has been provided with its own stock of government securities. These, in conjunction with therecently introduced electronic central depository system, will facilitate the development of interbank money

and securities markets, and provide the BOU with greater flexibility in managing bank liquidity. The

government's policy remains to allow interest rates to be determined through market forces.

15. The government will continue its efforts to develop a sound financial sector. Central to these efforts will be

the submission to parliament in 1999/2000 of a revised Financial Institutions Statute. The proposed statute

contains provisions for mandatory prompt corrective action by the BOU; an increase in the minimum required

capital from U Sh 500 million (U Sh 1 billion for foreign-owned banks) to U Sh 2 billion by January 2000 and

subsequently to U Sh 4 billion by January 2003 for all banks; and stricter limits on insider lending and

concentration of loans and share ownership. Meanwhile, the BOU will continue to enforce the provisions of

the existing statute as explained in the MEFP. Moreover, the BOU will strengthen its supervisory capacity

through staff increases, upgrading of skills, and technical assistance, with a view to developing the capacity to

examine all banks, at least once a year, by 2000/01. To maintain the momentum gained to date with regard to

the recovery of commercial bank nonperforming assets, the mandate of the Non-Performing Asset Recovery

Trust (NPART) has been extended for two years beyond the previous expiration date of October 1, 1999.

External sector policies

16. Uganda will continue to operate a market-determined foreign exchange system, as well as a free trade

regime. The government will continue to implement monetary and fiscal policies consistent with stability in

the foreign exchange and domestic money markets. In this context, the BOU will maintain its policy of

intervening in the foreign exchange market in response to temporary and reversible shocks, mindful of its

inflation and international reserves objectives.

17. Recognizing the links between poverty reduction, economic growth, and international trade, the

government will continue its trade liberalization program. In line with this approach, an automatic system of

duty drawback payments will be implemented in 1999/2000, and the waiting period for normal refunds will be

shortened. The temporary additional tariffs on beer, soft drinks, and automobile batteries will be completely

phased out by March 2001, while the discriminatory excise taxes on imported cigarettes and other tobacco

products will be fully eliminated by June 2001, with interim steps taking place in year 2000. In the context of

the Cross-Border Initiative (CBI), the Common Market for Eastern and Southern Africa (COMESA), and East

African Community (EAC), Uganda will continue to reduce tariffs and nontariff barriers to regional trade and



is committed to avoiding any discriminatory tariff increases. In this regard, discriminatory excise taxes, as well

as other measures granting protection to local industries, will be removed in the context of trade liberalization

undertaken within the EAC.

18. Capital account transactions were fully liberalized effective July 1, 1997. The new Foreign Exchange Bill,

which will supersede the Exchange Control Act and formalize the legal framework for the liberalization of

international capital transactions, has been submitted to the cabinet and is expected to come into force by end-

June 2000.

Other structural and institutional reforms

Public enterprise reform

19. Public enterprises will be rationalized through the privatization and/or restructuring of key public

enterprises. With respect to financial discipline, in 1999/2000 the government will stop accumulating arrears to

public enterprises as part of the package of measures envisaged to eliminate the accumulation of domestic

budgetary arrears. It is also committed to ensuring that by 2001 enterprises remaining in its portfolio are

financially restructured and put on a sound footing to limit their burden on the budget. To this end, the

government will set financial targets for the largest public enterprises, in order to better monitor their operating

efficiency. Restructuring public enterprises, particularly the utilities, to make them cost-efficient and viable,

will contribute to poverty eradication by (i) freeing up resources to finance social programs; (ii) boosting

private sector investment; and (iii) increasing the availability of services that matter to the poor, such as water

supply and transportation. The government's strategy is to introduce private sector participation and

competition in the infrastructure sectors and to regulate utilities independently and cost-effectively.

20. With respect to privatization, the government will ensure that the Privatization Unit moves expeditiously

with divestiture actions, immediately following parliamentary approval of proposed amendments to the Public

Enterprise Reform and Divestiture (PERD) Statute. Meanwhile, in consultation with the World Bank, the

government has begun to implement a new strategy whereby commercial enterprises are prioritized for

privatization according to their impact on the economy and the budget.

Public service reform and decentralization

21. Civil service reform and decentralization continue to be pursued within the context of the government's

public service reform strategy, which aims at (i) optimizing the size and structure of the civil service; (ii)

enhancing skills by improving training and evaluation and introducing pay reform; (iii) strengthening control

systems; and (iv) monitoring and improving operating efficiency and effectiveness. Beginning in 1999/2000,



the government will sharpen its focus on the effective delivery of services through the continued

implementation of the results-oriented management (ROM) and the outcome-oriented budgeting (OOB)

programs, and it will conduct the first National Service Delivery Survey (NSDS). Building on the substan-tive

progress already made in civil service ministerial restructuring, the government will eliminate excess staffing.

Upon completion of the ministerial restructuring, ministries will be allocated block cash grants for the paymentof their wage bills. The agreed restructuring of the public service has been extended to commissions,

secondary and tertiary education, police, prisons, other semiautonomous and autonomous bodies, and

delegated staff, and the sizes of their establishments will be fully streamlined by June 2000. The government

recognizes the importance of adequate remuneration of civil servants for the effective delivery of social

services.

22. The government will continue to focus on actions designed to improve the efficiency and effectiveness of

the public service delivery system within the framework of the decentralization that is under way. The

decentralization program aims at reinforcing poverty reduction by giving the local communities a bigger role

in the planning and execution of projects. During the three-year period, the capacity of districts to provide

services, implement projects, and monitor their physical operations will be expanded. Moreover, with effect

from the current fiscal year, an equalization grant will be provided to the least-developed districts. The

production of local government budget framework papers will be emphasized to improve the budget process

and better meet local government priorities. With technical assistance from the Fund, the World Bank, and

other donor agencies, efforts will continue to introduce by 2000/01 a harmonized district budget classification

and accounting system.

23. The Ministry of Public Service (MPS) will commission an actuarial study to analyze the current pension

system and assess its long-term financial requirements. The MPS is working on a proposed set of reforms in

the public pension scheme, including revisions to the benefit formula. The proposed set of reforms will be

incorporated in revised legislation to replace the current pay-as-you-go system with a defined benefit-

contributory system in line with international standards.

Sector policies

Agriculture

24. The government's vision for the agriculture sector is increased and sustainable agricultural production, with

enhanced productivity that effectively contributes to poverty eradication and ensures food security without

degrading the environment. The government is committed to transforming agriculture from a predominantly

subsistence sector into a commercially oriented one. A Plan for Modernization of Agriculture (PMA) will be

completed by December 1999. During the program period, the government is committed to increasing



spending on agricultural research and extension services; reorienting the approach to agricultural extension

services toward further decentralization; seeking some cost-sharing from districts, subcounties, and

beneficiaries; and improving the environment for private sector investment in agriculture.

Transportation

25. Recognizing the critical importance of rehabilitating and maintaining roads, the government is

implementing the first phase of the ten-year Road Sector Development Program (1996/97 – 2005/06). The

government's spending on this program has not been in line with its objectives and with donor funding, partly

because of implementation capacity constraints. To address these constraints, a Road Agency Formation Unit

(RAFU) has been established within the government as an interim measure to streamline project execution and

supervision. In 1999/2000, the government will initiate a study of the institutional and financial arrangements

necessary for the establishment of a fully independent roads agency by June 30, 2002.

26. Rural feeder roads are critical for increasing returns to farmers and are the main components of both the

PEAP and the agriculture modernization plan. To guide its interventions in rural feeder roads, the government

has completed a rural roads study and will in 1999/2000 develop a complete inventory of rural roads and

prioritize their importance as the basis for a medium-term investment plan for maintaining and rehabilitating

rural roads. This investment plan will address the relative balance between rehabilitation and maintenance, as

well as strengthen institutional capacity.

27. The government will assist in the modernization of water transport where it is identified as the important

means of transportation. At present, no conditional grants have been earmarked for water transport

development, which is not identified specifically in the PEAP as critical for increasing incomes of the poor.

However, the 1999 UPPA has revealed that water transport is the main transport mode in some areas. The

government will address this problem by promoting local community involvement in the planning of district

transport systems and by introducing flexibility in the conditional grants to allow districts to develop

infrastructures that best fit their priorities.

28. The Uganda Railways Corporation (URC) receives large government subsidies. In August 1999, the

cabinet approved a plan for increasing private sector involvement in the operation of the URC with the aim of

improving its operating efficiency. Privatization and restructuring advisors will be appointed by June 2000 to

evaluate the mechanisms for implementing the first stage of the restructuring. During the first stage, the URC

will be under private sector management. Regarding aviation, the government is privatizing Uganda Airlines

Corporation (UAC).

Power



29. Significant progress has been achieved in laying the groundwork for reform of the power sector. On June

30, 1999, the cabinet approved a plan for reforming the power sector to improve operational efficiency through

private sector competition. A revised electricity law has been passed by parliament that introduces private

sector competition in the various segments of the industry (i.e., generation, transmission, and distribution). The

power sector, as well as other utilities, will eventually be regulated by an independent, multisector PublicUtilities Commission. In the interim, sector-specific regulatory bodies will oversee electricity and

communications. Moreover, the recently created Utility Reform Unit is expected to take the lead in preparing

for privatization all public utilities enterprises.

30. The government is pursuing a least-cost strategy for the development of the country's abundant

hydroelectric potential. The first phase for the construction of the 20-megawatt Owen Falls Extension is

scheduled to be completed in 2000. The government will continue to pursue agreements with independent

power producers that are consistent with the potential growth of domestic and external demand and with the

new structure of the sector, as defined in the new sector reform strategy and legislation, and it will establish a

transparent process for evaluating the technical, financial, and environmental aspects of each project. The

restructuring and reform of the energy sector is central to the provision of low-cost power to consumers and

enterprises. As part of the government's commitment to introducing competition and private participation in

the sector, it plans to unbundle the activities of the Uganda Electricity Board (UEB) to facilitate private sector

involvement, in part through concessionary arrangements. The government is engaging technical experts to

assist in the implementation of the strategy. Meanwhile, the government will continue to improve the

operational performance of the UEB through actions designed to reduce energy losses, accounts receivable,

lower the UEB's operational ratio, and further downsize its workforce.

Water supply and environmental sanitation

31. Access to safe drinking water is still a problem for many Ugandans. The government continues to pursue

its objective of universal provision of safe water by 2015. In order to achieve this objective and to ensure long-

term sustainability, increased involvement of beneficiaries in the design and management of the systems is

being sought. Because of the sizable investments required over the next four years and the importance of these

investments for poverty eradication, the government is conducting a comprehensive review of its policies in

the water sector. The review will be completed by end-1999 for rural areas and by June 2000 for urban areas.Budget provisions for the water sector (including lands and environment) will increase by 40 percent in

1999/2000 to U Sh 21 billion (excluding projects contained in the externally financed development budget)

and to an average of U Sh 27 billion during the following two years. Reflecting this increased funding, over

214,000 people are expected to benefit from the completion of water supply projects in selected towns and

rural growth centers during the year 1999/2000. Moreover, completion of ongoing construction work on



freshwater sources (boreholes, springs, and shallow wells) will allow almost 720,000 people access to clean

water. By end-2000, access to clean drinking water is expected to reach 50 percent in rural areas and 68

percent in urban areas. The government expects to increase funding in the water sector further. As budget

outlays increase, efficiency improvements will be on the agenda. To this end, the government will restructure

the National Water Supply and Sewerage Corporation (NWSC), which is responsible for supplying water andwastewater services to Kampala and ten other towns. The NWSC performance indicators are poor and its

tariffs high. The government is investigating options to subcontract the NWSC's technical and commercial

operations to a private operator within the framework of a medium-term contract that would provide incentives

to improve performance. A decision on the appropriate approach will be made in 2000/01.

Telecommunications

32. Within one year of licensing a second telecommunications provider — in addition to Uganda

Telecommunications Limited (UTL) —

the number of telephone lines in Uganda has increased by about 48

percent. In the period ahead, the government will focus on completing the privatization of the UTL, which is

being retendered after two failed attempts. The Uganda Communications Commission (UCC) will be

strengthened to provide a regulatory environment conducive to investment and competition. The UCC will

later operate under a single regulatory body for all utilities to be established.

Contents

IV. Human Resource Development

33. The government strategy regarding human resource development remains as spelled out in last year's PFP.

Some specific measures are worthy of note regarding the focus on consolidating the Universal Primary

Education (UPE) program and improving health indicators.

34. The government will ensure adequate funding for the education sector in line with the Education Sector

Investment Program (ESIP). To improve the quality of teaching, the government will integrate the Teacher

Development Monitoring System (TDMS) into the Ministry of Education and Sports and provide the TDMS

with adequate funding to monitor and support the teaching-learning process in schools. The government will

link the assignment of the number of teachers and the allocations of capitation grants to the number of pupils

enrolled during the year in which resources are made available. The government plans to expand secondary

education in order to meet the increasing demand for access to secondary school. Given the resource constraint

and the number of stakeholders, the government will develop an expansion strategy involving partnerships

with parents, communities, NGOs, and the private sector.






35. In view of Uganda's poor health indicators, the government aims at improving health outcomes over the

medium term. Measures to improve health indicators are contained in the new National Health Policy and

Health Sector Strategic Plan (2000-05), both of which are in the final stages of preparation and ready for

adoption in 2000/01. The overall purpose of the new health sector program is to reduce morbidity and

mortality and the disparity in morbidity and mortality rates across the various groups and regions of thecountry. Under the new policy, the government's strategy for improving health outcomes will be based on (i)

imple-mentation of cost-effective interventions through a minimum health care package targeted to major

causes of ill health; (ii) adoption of a sector-wide approach (SWAP) for health; and (iii) establishment of

functional coordination mechanisms, at the center and district levels, for the national multisectoral response to

the HIV/AIDS epidemic. The implementation of SWAP is envisaged to commence during 2000/01.

Furthermore, based on the decentralization program, the government will continue to support the centers'

redefinition of its roles, strengthen the districts' coordination and delivery of health services, and prepare

districts to adopt and implement the new National Health Policy and Health Sector Strategic Plan.

Contents

V. External Financing Requirements and Debt Sustainability

36. The current account deficit is expected to decline as a result of the rapid growth in noncoffee exports, the

somewhat slower recovery of coffee export receipts, and the moderate increase in imports. In 1999/2000, the

value of coffee exports is projected to stagnate, as the continued weakness of international prices will offset the

gradual recovery of volumes. The slow pickup in prices from 2000/01 onward, combined with stronger

volumes, will significantly improve coffee export receipts in the subsequent years. Noncoffee exports are

projected to grow faster than coffee exports, reflecting the trends toward a more diversified economy. By

2001/02, noncoffee exports will account for more than half of total exports. By contrast, import growth is

expected to remain close to, or slightly above, the growth of real GDP. Private transfers are projected to grow

by an average of 8.6 percent per year until 2001/02, while inflows of foreign direct investment are expected to

improve as the economy grows and the reform process is deepened. In the circumstances, Uganda's balance of

payments is expected to record growing surpluses in the coming years.

37. The financing requirement for 1999/2000 amounts to US$1,047 million. It comprises a current account

deficit of US$579 million, scheduled amortization payments of US$77 million, an IMF repayment of US$50

million, a programmed accumulation of US$99 million in gross reserves — which will keep import coverage at

about five months of imports of goods and nonfactor services — and a reduction in external arrears of US$242

million. The financing requirement is expected to be met by the disbursement of official grants and loans for

nonproject and project financing (US$300 million and US$390 million, respectively), net private capital






inflows of US$13 million, along with a Fund disbursement of US$47 million and debt relief of US$297

million, including reschedulings and assistance received under the initial HIPC Initiative framework .6 The total

financing requirement over the three-year period is projected at US$2.5 billion and is expected to be covered

by nonproject loans and grants (US$769 million), project support (US$1.18 billion), IMF disbursements

(US$59 million), net private capital inflows of US$98 million, and debt relief of US$416 million. GivenUganda's uncertain terms of trade, the government will continue to target a reserve cover of about five months

of imports of goods and nonfactor services through 2001/02.

38. The government will continue its efforts to reduce Uganda's external debt burden, particularly in securing

from non-Paris Club creditors debt relief on terms at least comparable to the April 1998 Paris Club

rescheduling agreement. After accounting for debt relief under the first HIPC Initiative and an expected

rescheduling with non-Paris Club creditors, Uganda's external debt-service ratio is expected to fall to 11.7

percent of exports of goods and services by 2001/02 (against 18.4 percent in 1998/99).

39. The government's debt strategy aims to secure grants wherever possible, or else to borrow on highly

concessional terms, for projects that have high economic and social returns. The government will continue to

improve its capacity to monitor its external debt, to enable it to meet all its external debt-service obligations in

a timely and transparent manner. A permanent technical working group, comprising the debt and

macroeconomic units of the Ministry of Finance, Planning and Economic Development and the Bank of

Uganda, will continue its efforts to integrate debt analysis into policy formulation and to facilitate coordination

through quarterly reports within the government and to donors. With external assistance, capacity-building and

internal debt-management structures will be buttressed, and steps will be taken to ensure that debt-management

skills are disseminated widely among the core economic agencies.

Contents

VI. Technical Assistance Requirements

40. The government will continue to seek additional assistance as needed. With regard to fiscal operations,

additional technical assistance is envisaged in the areas of tax and customs administration and expenditure

management. Moreover, the Fund will continue to assist in implementing the improved financial managementand accounting systems over the program period, especially at the district level. In the monetary and financial

areas, the Bank of Uganda will seek technical assistance in improving financial sector supervision, the conduct

of monetary policy, and monetary statistics. The government will also be seeking technical assistance from the

World Bank in developing a detailed plan for the interim management and reprivatization of the Uganda










Commercial Bank. Assistance will continue to be sought in the areas of the civil service, pensions, public

enterprise reform, and preparation of economic and financial statistics.

1As measured by Simon Appleton, Tom Emwanu, Johnson Kagugube, and James Muwonge, "Changes in Poverty

and Inequality," Assessing an African Success: Firms, Farms and government in Uganda's Recovery, ed. Paul

Collier and Ritva Reinikka (Washington, D.C.: World Bank; forthcoming). The incidence of poverty is defined as

the proportion of the population living below the absolute poverty line, which is based on a minimum level of food

and nonfood requirements. The poverty line in Uganda is U Sh 16,443 (about US$14) per adult equivalent per

month in 1992/93 shillings.

2In addition, poor health, malnutrition, and illiteracy remain widespread, and immunization rates have fallen.

3The results of this assessment are presented in the government's poverty status report (1999).

4The World Bank has greatly contributed to the realization of the survey of firms and the preparation of the UPPA.

5

These reviews are attended by the media.6Possible enhanced HIPC Initiative assistance is not taken into account in these external financing assumptions.

Tables

Use the free Adobe Acrobat Reader to view Tables 1 – 4

I.T. SECURITY POLICYCopyright © Ruskwig – Ruskwig provides you with the right to copy and amend this document for your own use – Youmay not resell, ask for donations for, or otherwise transfer for value the document.

Page 1 IT Security Policy

http://www.imf.org/external/np/pfp/1999/uganda/ugtab.pdf


http://www.imf.org/adobe







TABLE OF CONTENTS

1. POLICY STATEMENT .......................................................................................................... 3

2. VIRUS PROTECTION ........................................................................................................... 5

3. PHYSICAL SECURITY OF COMPUTER EQUIPMENT ....................................................... 7

3.1. DEFINITIONS ................................................................................................................. 73.2. CATEGORIES OF RISK ................................................................................................ 83.3. REQUIRED PHYSICAL SECURITY .............................................................................. 93.4. COMPUTER SUITE ..................................................................................................... 14

4. ACCESS CONTROL ........................................................................................................... 15

5. LAN SECURITY .................................................................................................................. 17

6. SERVER SPECIFIC SECURITY ......................................................................................... 19

7. UNIX & LINUX SPECIFIC SECURITY ................................................................................ 21

8. WIDE AREA NETWORK SECURITY ................................................................................. 22

9. TCP/IP & INTERNET SECURITY ....................................................................................... 2310. VOICE SYSTEM SECURITY ............................................................................................ 24

11. GLOSSARY ...................................................................................................................... 25




I.T. Security Policy

1. POLICY STATEMENT

"It shall be the responsibility of the I.T. Department to provide adequate protection andconfidentiality of all corporate data and proprietary software systems, whether heldcentrally, on local storage media, or remotely, to ensure the continued availability of dataand programs to all authorised members of staff, and to ensure the integrity of all data andconfiguration controls."

Summary of Main Security Policies.1.1. Confidentiality of all data is to be maintained through discretionary and mandatory

access controls, and wherever possible these access controls should meet with C2class security functionality.

1.2. Internet and other external service access is restricted to authorised personnel only.1.3. Access to data on all laptop computers is to be secured through encryption or other

means, to provide confidentiality of data in the event of loss or theft of equipment.1.4. Only authorised and licensed software may be installed, and installation may only be

performed by I.T. Department staff.1.5. The use of unauthorised software is prohibited. In the event of unauthorised software

being discovered it will be removed from the workstation immediately.1.6. Data may only be transferred for the purposes determined in the Organisation‟s data-

protection policy.1.7. All diskette drives and removable media from external sources must be virus checked

before they are used within the Organisation.Page 3 IT Security Policy



1.8. Passwords must consist of a mixture of at least 8 alphanumeric characters, and mustbe changed every 40 days and must be unique.

1.9. Workstation configurations may only be changed by I.T. Department staff.1.10. The physical security of computer equipment will conform to recognised loss

prevention guidelines.1.11. To prevent the loss of availability of I.T. resources measures must be taken to backup

data, applications and the configurations of all workstations.1.12 A business continuity plan will be developed and tested on a regular basis.Page 4 IT Security Policy



2. VIRUS PROTECTION2.1. The I.T. Department will have available up to date virus scanning software for the

scanning and removal of suspected viruses.2.2. Corporate file-servers will be protected with virus scanning software.

2.3. Workstations will be protected by virus scanning software.2.4. All workstation and server anti-virus software will be regularly updated with the latestanti-virus patches by the I.T. Department.

2.5. No disk that is brought in from outside the Organisation is to be used until it has beenscanned.

2.6. All systems will be built from original, clean master copies whose write protection hasalways been in place. Only original master copies will be used until virus scanninghas taken place.

2.7. All removable media containing executable software (software with .EXE and .COMextensions) will be write protected wherever possible.

2.8. All demonstrations by vendors will be run on their machines and not the Organisation‟s.2.9. Shareware is not to be used, as shareware is one of the most common infection

sources. If it is absolutely necessary to use shareware it must be thoroughlyscanned before use.

2.10. New commercial software will be scanned before it is installed as it occasionallycontains viruses.

2.11. All removable media brought in to the Organisation by field engineers or supportpersonnel will be scanned by the IT Department before they are used on site.




2.12. To enable data to be recovered in the event of a virus outbreak regular backups willbe taken by the I.T. Department.

2.13. Management strongly endorse the Organisation's anti-virus policies and will make thenecessary resources available to implement them.

2.14. Users will be kept informed of current procedures and policies.2.15. Users will be notified of virus incidents.2.16. Employees will be accountable for any breaches of the Organisation's anti-virus

policies.2.17. Anti-virus policies and procedures will be reviewed regularly.2.18. In the event of a possible virus infection the user must inform the I.T. Department

immediately. The I.T. Department will then scan the infected machine and anyremovable media or other workstations to which the virus may have spread anderadicate it.


IT Security Policy

I.T. SECURITY POLICYCopyright © Ruskwig – Ruskwig provides you with the right to copy and amend this document for your own use – Youmay not resell, ask for donations for, or otherwise transfer for value the document.




TABLE OF CONTENTS

1. POLICY STATEMENT .......................................................................................................... 3

2. VIRUS PROTECTION ........................................................................................................... 5

3. PHYSICAL SECURITY OF COMPUTER EQUIPMENT ....................................................... 7

3.1. DEFINITIONS ................................................................................................................. 73.2. CATEGORIES OF RISK ................................................................................................ 83.3. REQUIRED PHYSICAL SECURITY .............................................................................. 93.4. COMPUTER SUITE ..................................................................................................... 14

4. ACCESS CONTROL ........................................................................................................... 15

5. LAN SECURITY .................................................................................................................. 17

6. SERVER SPECIFIC SECURITY ......................................................................................... 19

7. UNIX & LINUX SPECIFIC SECURITY ................................................................................ 21

8. WIDE AREA NETWORK SECURITY ................................................................................. 22

9. TCP/IP & INTERNET SECURITY ....................................................................................... 2310. VOICE SYSTEM SECURITY ............................................................................................ 24

11. GLOSSARY ...................................................................................................................... 25




I.T. Security Policy

1. POLICY STATEMENT

"It shall be the responsibility of the I.T. Department to provide adequate protection andconfidentiality of all corporate data and proprietary software systems, whether heldcentrally, on local storage media, or remotely, to ensure the continued availability of dataand programs to all authorised members of staff, and to ensure the integrity of all data andconfiguration controls."

Summary of Main Security Policies.1.1. Confidentiality of all data is to be maintained through discretionary and mandatory

access controls, and wherever possible these access controls should meet with C2class security functionality.

1.2. Internet and other external service access is restricted to authorised personnel only.1.3. Access to data on all laptop computers is to be secured through encryption or other

means, to provide confidentiality of data in the event of loss or theft of equipment.1.4. Only authorised and licensed software may be installed, and installation may only be

performed by I.T. Department staff.1.5. The use of unauthorised software is prohibited. In the event of unauthorised software

being discovered it will be removed from the workstation immediately.1.6. Data may only be transferred for the purposes determined in the Organisation‟s data-

protection policy.1.7. All diskette drives and removable media from external sources must be virus checked

before they are used within the Organisation.Page 3 IT Security Policy



1.8. Passwords must consist of a mixture of at least 8 alphanumeric characters, and mustbe changed every 40 days and must be unique.

1.9. Workstation configurations may only be changed by I.T. Department staff.1.10. The physical security of computer equipment will conform to recognised loss

prevention guidelines.1.11. To prevent the loss of availability of I.T. resources measures must be taken to backup

data, applications and the configurations of all workstations.1.12 A business continuity plan will be developed and tested on a regular basis.Page 4 IT Security Policy



2. VIRUS PROTECTION2.1. The I.T. Department will have available up to date virus scanning software for the

scanning and removal of suspected viruses.2.2. Corporate file-servers will be protected with virus scanning software.

2.3. Workstations will be protected by virus scanning software.2.4. All workstation and server anti-virus software will be regularly updated with the latestanti-virus patches by the I.T. Department.

2.5. No disk that is brought in from outside the Organisation is to be used until it has beenscanned.

2.6. All systems will be built from original, clean master copies whose write protection hasalways been in place. Only original master copies will be used until virus scanninghas taken place.

2.7. All removable media containing executable software (software with .EXE and .COMextensions) will be write protected wherever possible.

2.8. All demonstrations by vendors will be run on their machines and not the Organisation‟s.2.9. Shareware is not to be used, as shareware is one of the most common infection

sources. If it is absolutely necessary to use shareware it must be thoroughlyscanned before use.

2.10. New commercial software will be scanned before it is installed as it occasionallycontains viruses.

2.11. All removable media brought in to the Organisation by field engineers or supportpersonnel will be scanned by the IT Department before they are used on site.


Interested in learningmore about security?SANS Institute

InfoSec Reading RoomThis paper is from the SANS Institute Reading Room site. Reposting is not permittedwithout express written permission.Information Security Policy - A Development Guidefor Large and Small CompaniesA security policy should fulfill many purposes. It should: protect people and information;set the rules forexpected behaviour by users, system administrators, management, and securitypersonnel; authorize securitypersonnel to monitor, probe, and investigate; define and authorize the consequences ofviolation; define the

company consensus baseline stance on security; help minimize risk; and help trackcompliance with regulationsand legislation.Copyright SANS InstituteAuthor Retains Full RightsAD

© SANS Institute 200 7, Author retains full rights.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46



© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.Information Security Policy – A Development Guide for Large and Small CompaniesAuthor Version Date

Sorcha Canavan V1.0 11/18/03Sorcha Diver (previously Canavan) V2.0 07/12/06 © SANS Institute 200 7, Author retains full rights.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.ii1. Introduction....................................................................................................12. Why Do You Need Security Policy?.............................................................22.1 Basic Purpose of Policy .....................................................................22.2 Policy and Legislative Compliance.....................................................2

2.3 Policies as Catalysts for Change........................................................32.4 Policies Must be Workable.................................................................33. Who Will Use Your Policies? – Count Your Audiences..............................43.1 Audience Groups ...............................................................................43.2 Audience and Policy Content .............................................................44. Policy Types...................................................................................................64.1 Policy Hierarchy Overview .................................................................64.2 Governing Policy ................................................................................74.3 Technical Policies ..............................................................................74.4 Job Aids / Guidelines .........................................................................85. Policy Topics .................................................................................................95.1 Prioritizing Policy Topics ....................................................................95.2 Outline Topic List ...............................................................................95.2.1 Governing Policy ......................................................................95.2.2 Technical Policies...................................................................105.2.3 Job Aids / Guidelines..............................................................126. Policy Development Process......................................................................146.1 Development Approach....................................................................146.1.1 Development Process Maturity...............................................146.1.2 Top-Down Versus Bottom-Up.................................................146.1.3 Current Practice Versus Preferred Future ..............................156.1.4 Consider All Threat Types......................................................157. Policy Development Team..........................................................................167.1 Primary Involvement ........................................................................167.2 Secondary Involvement....................................................................168. Policy Development Lifecycle ....................................................................188.1 Senior Management Buy-in..............................................................188.2 Determine a Compliance Grace Period............................................188.3 Determine Resource Involvement....................................................18

© SANS Institute 200 7, Author retains full rights.



Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.iii8.4 Review Existing Policy .....................................................................19

8.5 Determine Research Materials........................................................198.6 Interview SMEs ................................................................................198.7 Write Initial Draft...............................................................................208.8 Style Considerations ........................................................................208.9 Review Cycles..................................................................................218.10 Review with Additional Stakeholders ...............................................218.11 Policy Gap Identification Process.....................................................228.12 Develop Communication Strategy....................................................228.13 Publish .............................................................................................238.14 Activate Communication Strategy ....................................................238.15 Regularly Review and Update..........................................................24

9. Policy Document Outline ............................................................................269.1 Introduction ......................................................................................269.2 Purpose............................................................................................269.3 Scope...............................................................................................269.4 Roles and Responsibilities ...............................................................269.5 Sanctions and Violations..................................................................269.6 Revisions and Updating Schedule ...................................................269.7 Contact information..........................................................................279.8 Definitions/Glossary .........................................................................279.9 Acronyms .........................................................................................2710.Troubleshooting ..........................................................................................2810.1 Policies Lack Weight ........................................................................2810.2 Lack of Reviewing Feedback ...........................................................2810.3 Resources Shortage ........................................................................2810.4 Reviews are Slow and Cumbersome ...............................................2910.5 Legislation Compliance Queries.......................................................2910.6 Policy is Quickly Out of Date............................................................2910.7 Policy is Unclear...............................................................................3010.8 People get Upset by the New Policy ................................................3011.Conclusion...................................................................................................31References ........................................................................................................32


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.ivAppendix 1: Governing Policy Outline............................................................34Appendix 2: Technical Policy Outline.............................................................36




© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.11. IntroductionAlthough the importance of information security for businesses is increasingly

recognized, the complexity of issues involved means that the size and shape ofinformation security policies may vary widely from company to company. Thismay depend on many factors, including the size of the company, the sensitivity ofthe business information they own and deal with in their marketplace, and thenumbers and types of information and computing systems they use. For a largecompany, developing a single policy document that speaks to all types of userswithin the organization and addresses all the information security issuesnecessary may prove impossible. A more effective concept is to develop a suiteof policy documents to cover all information security bases; these can betargeted for specific audiences, making a more efficient process for everyone.This paper examines the elements that need to be considered when developing

and maintaining information security policy and goes on to present a design for asuite of information security policy documents and the accompanyingdevelopment process.It should be noted that there is no single method for developing a security policyor policies. Many factors must be taken into account, including audience typeand company business and size, all of which are discussed in this paper. Oneother factor is the maturity of the policy development process currently in place.A company which currently has no information security policy or only a very basicone may initially use a different strategy to a company which already has asubstantial policy framework in place, but wants to tighten it up and start to usepolicy for more complex purposes such as to track compliance with legislation.When starting out it is a good idea to use a phased approach, starting with abasic policy framework, hitting the major policies that are needed and thensubsequently developing a larger number of policies, revising those that arealready in place and adding to this through the development of accompanyingguidelines and job aids documents which will help support policy. The varyinglevels of maturity in policy development are discussed later in this paper in moredetail.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.22. Why Do You Need Security Policy?2.1 Basic Purpose of PolicyA security policy should fulfil many purposes. It should:• Protect people and information • Set the rules for expected behaviour by users, system administrators, management, and security personnel• Authorize security personnel to monitor, probe, and investigate



• Define and authorize the consequences of violation1 • Define the company consensus baseline stance on security • Help minimize risk • Help track compliance with regulations and legislation Information security policies provide a framework for best practice that can be

followed by all employees. They help to ensure risk is minimized and that anysecurity incidents are effectively responded to.Information security policies will also help turn staff into participants in thecompany‟s efforts to secure its information assets, and the process of developingthese policies will help to define a company‟s information assets2. Information security policy defines the organization‟s attitude to information, and announces internally and externally that information is an asset, the property of theorganization, and is to be protected from unauthorized access, modification,disclosure, and destruction3.2.2 Policy and Legislative ComplianceIn addition to the purposes described above, security policies can be useful in

ways that go beyond the immediate protection of assets and policing ofbehaviour. They can be useful compliance tools, showing what the company‟s stance is on best practice issues and that they have controls in place to complywith current and forthcoming legislation and regulations.In today‟s corporate world it is essential for companies to be able to show compliance with current legislation and to be prepared for forthcoming legislation.Recent laws such as HIPAA (Health Insurance Accountability and PortabilityAct), GLB (Gramm-Leach-Bliley Act) and Sarbanes Oxley have had majorimplications for policy makers in the U.S. and farther a field. Policy can be usedto help companies ensure they have the controls in place to work towardscompliance by mapping policy statements to legislative requirements. In this waythey can provide evidence that their baseline security controls are in line withregulations and legislation. This type of stance will also give companies anindication based on legal requirements of what they need to protect and to what1 SANS GSEC Security Essentials Training Materials, 2003. p.336.2 Danchev, pp.2-3.3 Peltier, p.4.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.3extent. This will help to ensure that they target security controls only where theyare needed, a benefit from both a financial and personnel resourcing perspective.2.3 Policies as Catalysts for ChangeIt is also possible to use policies to drive forward new company initiatives, withpolicy acting as the catalyst for future projects which move towards bettersecurity and general practices. For example, a policy stating that a certain typeof encryption is required for sensitive information sent by email may (with priorconsultation with the appropriate technical experts) help to promote the need to



develop such a capacity in the future. The presence of this requirement in policyhas made sure the impetus to develop the email encryption project has remainedstrong.In short, security policy should be a useful tool for protecting the security of theEnterprise, something that all users can turn to in their day-to-day work, as a

guide and information source. All too often however, security policies can end upsimply as “shelfware”4, little read, used, or even known of by users and disconnected from the rest of company policy and security practice.2.4 Policies Must be WorkableThe key to ensuring that your company‟s security policy is useful and useable is to develop a suite of policy documents that match your audience and marry withexisting company policies. Policies must be useable, workable and realistic. Inorder to achieve this it is essential to involve and get buy-in from major players inpolicy development and support (such as senior management, audit and legal)as well as from those people who will have to use the policies as part of the dailywork (such as subject matter experts, system administrators and end users).

In order to achieve this, one important element is to communicate the importanceand usefulness of policies to those who have to live by them. Often users seemto think that policy is something that is going to stand in the way of their dailywork. An important element of policy development, and to ensure policies areput into practice and not rejected by the users, is to convey the message thatpolicies are useful to users: to provide a framework within which they can work, areference for best practice and to ensure users comply with legal requirements.Once users realise that policy is something that may actually help them as theydo about their work, they are much more likely to be receptive to both helpingyou develop it and living up to it to ensure compliance. Similarly, once seniormanagement realise that policy is a tool they can leverage to help ensureadherence to legislative requirements and to move forward much needed newinitiatives, they are much more likely to be supportive of policy in terms offinancial and resourcing support as well as becoming policy championsthemselves.4 Desilets, p.1.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.43. Who Will Use Your Policies? – Count Your Audiences3.1 Audience GroupsYour audience is of course all your company employees, but this group can bedivided into audience sub-categories, with the members of each sub-categorylikely to look for different things from information security policy. The mainaudiences groups are:• Management – all levels• Technical Staff – systems administrators, etc• End Users



All users will fall into at least one category (end-user) and some will fall into twoor even all three.3.2 Audience and Policy ContentThe audience for the policy will determine what is included in each policydocument. For example, you may not always want to include a description of

why something is necessary in a policy - if your reader is a technical custodianand responsible for configuring the system this may not be necessary becausethey are likely to already know why that particular action needs to be carried out.Similarly, a manager is unlikely to be concerned with the technicalities of whysomething is done, but they may want the high-level overview or the governingprinciple behind the action. However, if your reader is an end-user, it may behelpful to incorporate a description of why a particular security control isnecessary because this will not only aid their understanding, but will also makethem more likely to comply with the policy5.Allow for the fact that your readers will want to use the policies in a number ofways, possibly even in more than one way at one time. For example, when first

reading a policy document, an end-user may be interested in reading the entiredocument to learn about everything that they need to do to help protect thesecurity of the company. On another later occasion however, the user mayreference the document to check the exact wording of a single policy statementon a particular topic.Given the variety of issues, readers, and uses for policy, how can we hope toaddress them in one document? The answer is that we can‟t. Companies must ensure that their information security policy documents are coherent withaudience needs and to do this it is often necessary to use a number of differentdocument types within a policy framework. Which type of document you use willbe determined in large part by the audience for that document. For example, anoverall Acceptable Use Policy will be in the form of a higher level document,while a document that describes how to configure the instant messaging system5 Russell, p.5.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.5to ensure it complies with the Acceptable Use Policy may be in the form of a jobaid or guidelines document. Manager and end users are likely to be interestedthe former, while administrative staff are more likely to use the latter.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.64. Policy Types4.1 Policy Hierarchy OverviewThe diagram below outlines a hierarchical policy structure that enables all policy



audiences to be addressed efficiently. This is a template for a policy hierarchyand can be customized to suit the requirements of any company:The diagram above shows a hierarchy for a fairly mature, developed process,probably aligned to that possible in a large company where policy developmenthas been underway for several years. For smaller companies or for those just

starting to develop policy, it is possible to use this basic framework, but to initiallyhave a smaller number of Technical Policies and possibly no guidelines or jobaids early in the process. Rather than trying to develop a large hierarchy all atonce, it is more realistic to develop a Governing Policy and a small number ofTechnical Policies initially, then increase the number of policies and supportingdocuments, as well as the complexity of the policies as you move forward.As we have seen, in large companies there will be several audiences for yourpolicy, and you will want to cover many different topics on different levels. Forthis reason, a suite of policy documents rather than a single policy documentworks better in a large corporate environment. The hierarchical structure of thesuite of security policy documents reflects the hierarchical structure of roles in a

TechnicalPolicy(Multipledocuments)GoverningPolicy(Single document)TechnicalPolicy(Multipledocuments)TechnicalPolicy(Multipledocuments)TechnicalPolicy(Multipledocuments)TechnicalPolicy(Multipledocuments)TechnicalPolicy(Multipledocuments)Guidelines / Job Aids / Procedures



(Multipledocuments)Guidelines / Job Aids / Procedures

(Multipledocuments)Guidelines / Job Aids / Procedures(Multipledocuments)Guidelines / Job Aids / Procedures(Multiple

documents) © SANS Institute 200 7, Author retains full rights.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.7large company. The proposed scheme provides for all levels of audience and forall topics by using two policy types supported by procedural documents:• Governing Policy • Technical Policy• Job Aids / Guidelines 4.2 Governing PolicyGoverning Policy should cover information security concepts at a high level,define these concepts, describe why they are important, and detail what yourcompany‟s stand is on them. Governing Policy will be read by managers andend users. By default it will also be read by technical custodians (particularlysecurity technical custodians) because they are also end users. All these groupswill use the policy to gain a sense of the company‟s overall security policyphilosophy. This can be used to inform their information security-relatedinteraction with business units throughout the company.Governing Policy should be closely aligned with existing and future HR (HumanResources) and other company policies, particularly any which mention securityrelatedissues such as email or computer use, etc. The Governing Policydocument will be on the same level as these company-wide policies.Governing Policy is supported by the Technical Policies which cover topics inmore detail and add to these topics be dealing with them for every relevanttechnology. Covering some topics at the Governing Policy level may helpobviate the need for a detailed technical policy on these issues. For example,stating the company‟s governing password policy means that details of specificpassword controls can be covered for each operating system or application in the



relevant technical policy, rather than requiring a technical policy on passwordcontrols for all systems. This may not be the case for a smaller company, wherefewer systems/applications are used and where a single technical passwordpolicy would therefore be sufficient. For a larger company however, the formermethod provides a more efficient process for users to follow because they will

have to reference fewer documents – simplifying this process raises the oddsthat users will comply with the policy, thereby improving security.In terms of detail level, governing policy should address the “what” in terms of security policy.4.3 Technical PoliciesTechnical Policies will be used by technical custodians as they carry out theirsecurity responsibilities for the system they work with. They will be more detailedthan Governing Policy and will be system or issue specific, e.g., an AS-400Technical Policy or a Technical Physical Security Policy.Technical Policies will cover many of the same topics as Governing Policy, aswell as some additional topics specific to the overall technical topic. They are the

© SANS Institute 200 7, Author retains full rights.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.8handbook for how an operating system or a network device should be secured.They describe what must be done, but not how to do it - this is reserved forprocedural documents which are the next detail level down from Governing andTechnical Policy.In terms of detail level, Technical Policy should address the “what” (in more detail), “who”, “when”, and “where” in terms of security policy. 4.4 Job Aids / GuidelinesProcedural documents give step-by-step directions on the „how‟ of carrying out the policy statements. For example, a guide to hardening a Windows server maybe one or several supporting documents to a Technical Windows Policy.Procedures and guidelines are an adjunct to policy, and they should be written atthe next level of granularity, describing how something should be done. Theyprovide systematic practical information about how to implement therequirements set out in policy documents. These may be written by a variety ofgroups throughout the company and may or may not be referenced in therelevant policy, depending on requirements.Procedural documents may be written where necessary in addition to and insupport of the other types of policy documents, to aid readers in understandingwhat is meant in policy through extended explanations. Not all policies willrequire supporting documents. Beware however, if you find yourself gettingrequests for job aids for every policy document you write, your originaldocuments may be too complex or hard to understand. Save you and yourreaders time by ensuring everything you write is clear, concise, andunderstandable in the first place.The development of these supporting documents need not necessarily be



undertaken by the policy development team who develop the Governing andTechnical policies. It may be more efficient to have the individual business unitdevelop their own supporting documents as needed, both because of theavailability of resources on the policy development team and because thetechnical staff in the business units are likely to have the most complete and upto-

date technical knowledge in the company, better enabling them to write suchdocuments. The policy gives them the framework to follow (the “what”, “who”, “when”, and “where” in terms of security policy) and they simply need to follow these controls and sketch out the “how”. Job aids and guidelines will also act as a backup facility if a staff member leaves,ensuring their knowledge isn‟t lost and that policy requirements can still be carried out.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.

95. Policy Topics5.1 Prioritizing Policy TopicsWhen you begin to write security policy you will need to prioritize what topicsneed to be addressed first. A number of factors should be taken into accountduring this process. First, look at any areas containing information that you arelegally obliged to protect. These areas will be defined (although not alwaysclearly) in national, state, or local government laws. Secondly, look atinformation that may be used in critical decision-making by your organization oryour customers. You may also be legally liable for compromises to theconfidentiality or integrity of this information6.The remaining information should be prioritized according to business criticalityand sensitivity, that is, how critical the information is to the continuation of yourcompany‟s business processes and how much damage would result from unauthorized disclosure of the information. This will enable you to see whichinformation is more sensitive. Your company‟s information security group may already have carried out a risk assessment, the results of which will help todetermine which are priority policy topics.5.2 Outline Topic ListWhen you have prioritized your information using the guidelines above, you canthen begin to break it down by area into separate policy documents. Divide yourtopics by issue, system, application, technology and general. You are then readyto determine which topics you need to reference in Governing Policy and whichalso need a separate Technical Policy of their own.5.2.1 Governing PolicyGoverning Policy should cover all aspects of security at a higher, broaderlevel than the detail contained in the Technical Policies. All major,baseline security topics need to be covered. This is the place to state thecompany‟s baseline stance on these issues. When first developing a Governing Policy where none previously existed



the main concern may be to cover the main topics, while subsequentrevisions may incorporate more company-specific topics as feedback isreceived and the policy development team has more familiarity with whatissues need to be addressed.The list of what can be included here is therefore virtually endless, but a

starting point can be the sample Governing Policy outline in Appendix 1.6 www.itsc.state.md.us/info/InternetSecurity/BestPractices/SecPolicy.htm, pp.1-2. © SANS Institute 200 7, Author retains full rights.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.105.2.2 Technical PoliciesThe number of Technical Policies required will depend on the number ofoperating systems, applications, and other technologies used by yourcompany. Listed below are some categories that can be used to identify

policy needs in each area. Each entry in a category represents a singleTechnical Policy document. This is by no means an exhaustive list andwhile the list for any given company will be dictated by the technologies inuse by the company, some policies will be almost universal and mostcompanies will need to consider developing a policy for these areas. Thismay seem like a large number of policies, but remember that the audiencefor these documents are technical people who work specifically with thesetechnologies. Therefore, most technical staff will only have to read andknow about the content of one or two technical policies. Informationsecurity employees will have to be familiar with a greater number of thedocuments.Another way of structuring technical information security policies is togroup by security topic, e.g., one policy on authorization, another onauthentication, another on securing sensitive information, etc. There aretimes when this works well (physical security, privacy) and times when itisn‟t so successful (authentication, authorization), particularly for companies whose policy development model hasn‟t reached full maturity. The company‟s baseline stance on authentication fits comfortably into the Governing Policy for example, but when it comes to the detail onauthentication (differences between platforms, etc) this is best tackled inthe Technical Policy for as many technologies as need it rather than in asingle authentication policy.The reason for this is clear if you think again about how your users arelikely to use the policy. Most users who need more detail than iscontained in the Governing Policy will be searching for policy statementson a given technology (“I need to secure this Windows server, can you point me to the correct policy, please”) rather than on a given topic. Therefore they would not welcome having to searching through policies onauthentication, authorization and auditing to find out how to configure agiven operating system or application.



The list below is a sample list of some of the policies a company mightexpect to develop7. Note however that the universal list is virtuallyendless and therefore each company‟s list will be different. Depending on how your company is set up, you may also group these policies differently,for example it may make sense to include your policy statement on VPN in

your Remote Access Technical Policy in some cases. Another companymight decide to have a single Technical Policy dealing with all peripheraldevices while a larger company which uses many types of these devicesmight decide to have several policies dealing with individual devices types.7 This list is based on my own experience with the addition of suggested policies fromGuel, p.11.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.11

Operating SystemsWindowsUNIXLinuxMac OSOS400zOSSolarisApplicationsApplications (a single document covering applications development policy,including policy for web, vendor, and in-house applications)OracleDB2SQL ServerSAPB2BIMSNetworkRouter / SwitchRemote Access / VPNExtranetWirelessExchangeWeb ConferencingBusiness Planning / AdministrationAcceptable UseAcquisition / Procurement AssessmentBusiness ContinuityDisaster RecoveryEmail Usage



AuditCustomer AuthenticationPrivacyThird-Party / Service ProviderPatching

© SANS Institute 200 7, Author retains full rights.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.12Risk AssessmentInformation Sensitivity / PrivacyInformation Management (including retention policies)PasswordAccess ReverificationData Classification

Security DevicesIDS (Network and Host-based)FirewallAnti-VirusPeripheral DevicesCopiers, printers, and fax devices)Voice Communications (including VOIP)PDAs and other portable devices such as USB keys, flash drivesCDs/DVDsCryptographyEncryptionKey ManagementPhysical SecurityPhysical SecurityLab SecuritySee the sample outline in Appendix 2 of this document for more detail onwhat a Technical Policy should look like.5.2.3 Job Aids / GuidelinesThe possible list of procedural documents a company might need isperhaps even more varied than the technical policy list. As these may bedeveloped based on policy by individual business unit‟s rather than by the policy development team, in a large company you may not even know howmany are out there. In other circumstances the policy development teamwill assist with the development of these documents.Some example procedural documents are:• Coding Guidelines: These will be developed for each programming language or coding environment used in a company and can be asdetailed as necessary. They will include practical examples of




© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.13secure coding methods as well as broader secure coding policystatements. Input from the developers themselves is essential

here.• Business Recovery Plan Guidelines: These will describe the process for developing and maintaining a business recovery plan,including details such as roles and responsibilities of who owns theplan, who has the ability to update it, etc. In addition the guidelinescould list the required plan elements and how often the plan shouldbe tested.



146. Policy Development Process6.1 Development Approach6.1.1 Development Process MaturityThe major consideration behind any company‟s policy development process will be the level of process maturity. It is important thatcompanies (especially larger ones) don‟t aim too high initially and try todevelop a comprehensive and complex policy program straight away.This isn‟t likely to be successful for a number of reasons including lack of management buy-in, unprepared company culture and resources andother requirements not in place. In this situation it is advisable to start offsmall, perhaps developing checklist –style policies initially and only askeleton policy framework with essential policies developed first.As the process grows in maturity, companies will be able to develop thefull range of policies with more detail included in each as well asaccompanying procedural documentation as needed. Education,awareness and communication processes will also grow in maturity tocope with promoting an ever-growing range of policies. This shouldcoincide with the growing corporate strength of the policies themselves.The corporate culture will start to appreciate that the policies must befollowed and may actually start to use them to push through much neededchanges throughout the company.6.1.2 Top-Down Versus Bottom-UpThere are many starting points for developing policy. New or forthcominglegislation can often be a powerful impetus to develop policy, as canrecent security incidents or enthusiastic administrators recently returnedfrom the latest training course. All these provide great inputs to policy butthe key is to be balanced. Relying solely on the „top -down‟ approach of using only legislation, regulations and best practice to write your policy willleave you with unrealistic, artificial policy that won‟t be workable in the real



world. Similarly, relying only on a „bottom-up‟ method based only on system administrator knowledge can result in policy that is too specific to agiven environment (perhaps just one part of a large company), possiblybased too much on local current practice or on the latest trainingsuggestions, making it too unrealistic. The best policy will come from a

combination of these approaches, both top-down and bottom-up. In orderto achieve this it is something that must be considered from the outset andmust be reflected in the diversity of areas involved in policy developmentand the types of review policy undergoes.This balanced approach is likely to result in a more mature policydevelopment process. It can work for both small companies (where thereis little space between top and bottom) and big companies where the



15breadth of knowledge is needed to ensure a realistic and workableresulting policy.6.1.3 Current Practice Versus Preferred FuturePolicy development must also take into account to what extent the policyshould reflect current practice versus preferred future. Writing a policythat reflects only precisely what is done today may be out-of-date even bythe time it is published, while a policy that includes controls which cannotyet be feasibly implemented may be impossible to comply with fortechnical reasons and may therefore be ignored as unrealistic andunworkable. It is important that this is discussed at an early stage as if itis not discussed and the policy develops too far towards the unworkable,preferred future model, this may only then show up at the policy gapidentification stage, when a lot of time and effort will then have beenwasted developing something which is of little value. The best policystrikes a balance between current practice and preferred future and this iswhat the policy development team should aim for.6.1.4 Consider All Threat TypesFinally when considering what should be included in an initial draft, makesure to consider all the types of threats your company faces. While thosefrom malicious external attackers in the form of viruses and worms attractmuch media attention and accordingly deserve to be considered whenwriting policy, other considerations that are at least as important includenatural disasters, disgruntled current and former employees andignorance leading to accidental security exposures. Policies shouldconsist of controls to combat all these threat types.





167. Policy Development TeamIt is important to determine who is going to be involved in the actual developmentphase of policy at an early stage. The group who develops the policy shouldideally also be the group who will own and enforce the policy in the long-term;

this is likely to be the information security department.The overall composition of the policy development team will vary according to thepolicy document being developed, but the following is a list of individuals orgroups who may be involved.7.1 Primary Involvement• Information Security Team – A team or part of a team from this groupshould be assigned the overall responsibility for developing the policydocuments. Overall control may be given to one person with others ina supporting role. This team will guide each policy document throughdevelopment and revision and should subsequently be available toanswer questions and consult on the policy.

• Technical Writer(s) – Your company or security department mayalready have a technical writer on staff who can assist in writingsecurity policies. Even if they are not able to take primaryresponsibility for the information security policy project, an in-housetechnical writer can be a valuable resource to help with planning yourpolicy project, determining an appropriate style and formattingstructure for your documents, and editing and proof-reading your policydrafts.7.2 Secondary InvolvementThe following groups may (and in some cases, should) have input duringthe development of the policy in reviewing and/or approval roles.• Technical Personnel – In addition to staff on the security team, youmay need to call upon the expertise of technical staff who have specificsecurity and/or technical knowledge in the area about which you arewriting. They will be familiar with the day-to-day use of the technologyor system for which you are writing policy, and you can work with themto balance what is good security with what is feasible within yourcompany.• Legal Counsel – Your Legal department should review the policydocuments once they are complete. They will be able to provideadvice on current relevant legislation such as HIPAA and Sarbanes-Oxley, etc that requires certain types of information to be protected inspecific ways, as well as on other legal issues. The Legal departmentshould also have input into the policy development process in terms of


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.17letting the policy development team know about forthcoming legislative



requirements and helping to decipher these for the team.• Human Resources – The Human Resources department may need toreview and/or approve your policy depending on how you havedetermined that your policy will relate to existing company policies.Where your policy touches on topics covered by existing HR policy,

e.g., email usage, physical security, you must make sure that both setsof policy say the same thing.• Audit and Compliance – The Internal Audit department in yourcompany are likely to be involved in monitoring company-widecompliance with the policy once it is in force. It is therefore useful ifthey are involved in the development and review processes for policyto ensure that it is enforceable in terms of their procedures and currentbest practice. If there are other compliance groups additional to themain internal audit department, these groups should also be consultingas needed.• User Groups – During revision of policy documents, it can be useful to

work with users to determine how successful current policy is, andthereby determine how the policy may need to be changed to make itmore useable for your target audiences. Issues such as the style,layout, and wording of your policy documents may seem minor issuescompared to their content, but remember that if your documents areoff-putting or hard to understand, users may not read them fully or mayfail to understand them correctly, thereby needlessly risking securitycompromise.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.188. Policy Development LifecycleOnce you have determined who will be involved in writing the policy, you canbegin the policy development process.8.1 Senior Management Buy-inDeveloping a suite of policy documents will require a high level of commitment,not just from the primary developer and development team, but also from anumber of other information security personnel in the company. In order to makesure that these resources are available to you for the time you need to get theinformation you need, management buy-in must be sought at the beginning ofthe policy project. Management must be made aware of both the importance andsize of the task ahead so that they will not baulk at resource allocation in the laterstages.Senior management also supports the policy development and maintenanceprocess by championing the resulting policies throughout the company andputting their weight behind them so that the policy is seen to have “teeth”. Further, they should be prepared to support projects that result from policy toensure compliance. These two types of support are essential to the ongoing



viability of the policy program.8.2 Determine a Compliance Grace PeriodAt the beginning of your overall policy development project, you should work withthe Internal Audit group to determine how soon after policy publication they willaudit based on the policy. By allowing a grace period for compliance, you are

helping to ensure that the policies will be enforceable. This grace period willensure those users who have to live by the policies have enough time to reviewthem and implement any project, processes or internal communicationsnecessary to make sure they are in compliance. Depending on the size of thecompany, the grace period can be anything from a few months to around oneyear.8.3 Determine Resource InvolvementAt this point you should identify who you will need to talk to in order to determineand agree on the content of the policy. See the Policy Development Teamsection for the categories of people who may need to be involved.You must give all team members an estimate of how much of their time they can

expect to allocate to the project. Policy projects held up because subject-matterexperts (SMEs) are busy can mean that the policy risks being out of date beforeit is finished. If necessary, get buy-in directly from line managers. In most cases,people will see the value of policy and will be happy to help you developsomething that will help them in their jobs, but you need to make sure they are onboard before going any further.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.198.4 Review Existing PolicyIf your company has any existing security policy, review it to determine if it canbe used as part of the new suite of policy documents. Collect all relatedprocedures and guidelines as well as any high level policy documents. Thesecan all be used to get an idea of current company stance on a given issue ortechnology, or simply to show that a certain technology is secured differently indifferent areas of the company. This is something that will need to be reflected inthe new policy document. Even existing guidelines or job aids can become thestarting point for a policy document on the same topic.8.5 Determine Research MaterialsAs well as talking to SMEs and other experts and drawing on your ownknowledge of information security, you may need to do research for some policytopics. This is particularly the case for „new‟ technologies such as instant messaging, smartphones, or topics that your company has not previously had anofficial security policy on. In these cases, you will need to research industry bestpractices, and there are a number of sources you can use for this - I have listedsome below:• Internet – As well as visiting information security websites, (e.g.,www.securityfocus.com) use web search engines to find information on



security topics. However, stick to reliable sources and be aware thatsome of the information may not be current.• SANS – The papers in the SANS reading room provide excellentinformation on security topics which can be used as research material forpolicy topics.

• Journals, books, white papers – Again, by aware of how up to date thesesources are. In the fast-moving infosec world, books may soon get out ofdate; journals may be a better source in these cases.8.6 Interview SMEsBefore the interview itself, there are things you can do to ensure you get the bestfrom your SMEs8.• Define your objectives – know as much about the topic as you can, anddetermine what level of detail and information you require from the SME.The detail you require will depend on what type of policy document youare working. Let your SME(s) know what your objectives are so that theytoo can be prepared.

• Prepare for the meeting – arrange a suitable meeting place or book aconference bridge. Compile a list of questions or an outline of topics youwant to cover.• Control the interview – listen actively, ask open-ended questions andcontrol the flow of the interview. Where SMEs disagree or go off ontangents, aim to bring them back to the focus of the discussion without8 Lambe, p.30.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.20getting into arguments about opinions. Take notes and write everythingdown. Ask questions if you are not clear on any points.• Sum up and confirm – sum up what you have understood from theinterview and what your next steps are. Iterate anything that is expectedfrom the SME before or in time for the next meeting. Thank them for theirtime.• Post-interview review – organize your materials, and review your noteswhile they are still fresh in your mind and on paper.8.7 Write Initial DraftDetermining the right pitch or level for the policy can make the differencebetween a feasible security policy and one that is merely shelfware. Make thepolicy too rigid and it will be unenforceable, but make it too weak and it willprovide insufficient protection. Be aware that there may well be exceptions tosome of the policy statements. In these cases, it is acceptable to leave thestatements in the policy, but to refer the exceptions to the deviations process9.This ensures that the company policy is clearly stated and enforced according torisk assessment and best practices, while at the same time providing amechanism for dealing with occasional exceptions without weakening the policy.



Even if you don‟t have fully formed policy statements at this point, it is a good idea to get something down on paper before your first review meeting with therest of the project team. Even a list of topic headings and questions is easier towork from than a blank page.8.8 Style Considerations

The following style guidelines will help to ensure your policies are useable:• Consult your corporate style guide. If one exists, this will be an easy wayto ensure all your policies have the same look and feel and will also helpthem to be more quickly accepted as corporate documents. If you don‟t have a style guide, consider developing one to ensure consistencythroughout your policies. This will also make them easier to update andreview.• Ensure you have a consistent style throughout. There is much debate about the passive voice versus the active voice; whichever you use, choseone and stick to it throughout to aid comprehension.• Be clear and use concrete rather than abstract language, e.g., say “log

files must be reviewed at a minimum annually” rather than “log files must be reviewed regularly”. What is considered “regular” will differ from person to person and your policy must mean the same to everyone so thatit can be followed consistently.9 This process allows for requests for deviations from policy to be reviewed by acompany‟s information security group. Deviation applications are reviewed to determine if a deviation may begranted based onbusiness needs, taking account of the risk to security. In many cases, deviations aretemporary or on asmall scale and do not present the security risk they would if allowed on a company-wide, permanent basis.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.21• Avoid using very negative statements such as “never”. Using overly strong negatives sets up gradations of prohibition that are unhelpful whenyou want to present clear, useable policy that either allows or disallowsactions, or presents exceptions clearly. In the following example, the firstpolicy statement weakens the second because of the statement that oneaction “must never” be done while the other is prohibited with the, by comparison softer, “must not”: o “Passwords must never be shared. o Passwords must not be written down.” • Use simple, easy to understand language and pare it down to a minimum. All your readers must be able to understand your policy, and theyshouldn‟t have to wade through reams of information to get to the point. • Use “must” for “shall” and “will”, where “must” is what you mean. You will



therefore avoid inconsistencies in using “shall” and “will” and will not be mistaken for talking about the future.• Don‟t include anything that isn‟t policy in the policy statements section of the document. Background information, for example, should go in asection of its own, either at the start of the document or in an appendix.

You will weaken your policy statements by mixing them with informationalstatements. Similarly, procedural information should go in separateguidelines documents.• Where you use bulleted lists in policy, ensure that all items in the list are grammatically similar. For example, if the list starts out as a list of nounswith modifiers, it shouldn‟t include any items that are verb phrases. • Don‟t include the names of individuals in policy. People are likely tochange job rile more frequently than you will change the policy. Insteaduse job role names or department names, e.g., “the DBA team manager”. 8.9 Review CyclesReview the draft with the project team as often as you need to ensure it is

complete and correct and they are happy with it. Then make a final check ofyour document to ensure that you have followed the style guides outlined above.In addition, carry out a final spelling and grammar check and have yourdocument proof-read by someone who wasn‟t involved in its development - thiswill help ensure that it is understandable and clear.8.10 Review with Additional StakeholdersDuring this review phase the policy should be reviewed by any groups who havean interest in the policy. This includes any groups who will be expected to workwith the policy, who may have knowledge that needs to be taken into accountwhen developing with the policy, or who are able to help ensure that the policy isenforceable and effective. Such groups include the legal and internal auditdepartments. In addition, regional offices should be considered here, they willhave to comply with the policy, but their requirements may be different fromthose of the central office and this should be considered in this review phase.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.228.11 Policy Gap Identification ProcessBefore publishing policy, it is a good idea to determine which (if any) policystatements are not currently in force in your organization. These are known asgaps. Document any such gaps and determine which groups or individuals areresponsible for closing them. Include these groups in the discussion and letthem know that this policy will shortly be published and will have an impact ontheir working practice. This will ensure that people are prepared for thepublication of the policy and no one will be deluged with enquiries uponpublication. You will need to inform any groups identified during the gapidentification process for each policy of the time-scale of the grace period forcompliance so that they can plan towards future compliance.



If you‟ve pitched your policy correctly, you shouldn‟t find a very large number of gaps. Finding that every statement in the policy is actually a gap indicates that itis pitched too far towards a preferred future state and you may need to rethinksome or all of the content.Once you have identified any gaps, it is a good idea to keep a record of the gaps

for each policy somewhere (e.g., in a database or even simply a spreadsheet).This should be checked regularly to see if any of the gaps are now closed or ifany have passed the compliance grace period and need to be revisited. Thisrecord will also be a useful resource when you come to revise the policy in thefuture. Maintenance of this record may be the responsibility of the policydevelopment team, the wider information security team or other areas such asInternal Audit. Make it clear where this responsibility lies at the outset.8.12 Develop Communication StrategyAlthough the policy will be constantly available for company employees, you willinitially need to make them aware of new or updated policy. Work with yourcommunications or security awareness group to do this. Ensure that all

appropriate management groups are informed, so that they can filter downinformation in their area.It stands to reason that if policy is not read it will not be adhered to, so don‟t underestimate the importance of successfully communicating policies to thevarious audience groups. Depending on the size of the company and thematurity of the policy development process this will be more or less complex.Smaller companies have an easier job in one way in that it is logistically easierfor them to reach all employees and let them know what they should be readingand following. It is also likely that smaller companies will have fewer policies fortheir employees to read since they will usually have fewer technologies in use.However, even getting employees to read the Governing Policy can be achallenge, especially existing employees when the policy changes. Here are afew suggestions for how to tackle this:• Make it a contractual requirement: This is usually reserved for HR-ownedpolicies which employees must adhere to as part of their employmentcontract. However, because of the growing importance of informationsecurity in the corporate world, there is a growing argument for having


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.23employees sign up to information security policies as well as general HRpolicies.• Make policy part of required training: Incorporating information security policies into a training course (or courses) and making it a requirement foremployees to complete these courses annually is another way to ensurepolicies get read and hopefully adhered to following course completion.• Use a subscription-based communication method: One more advancedmethod of getting policies right under the noses of the employees who



need to read them, and ensuring that the employees actually want to readthem rather than considering them a nuisance, is to offer a subscriptionbasedservice where employees sign up to receive whichever policies aremost appropriate for them. This „sign up for security‟ method is something that could be activated when employees join the company, but could

include a facility for employees to update their subscription optionswhenever they want to, for example if they move departments or change job role. While for larger firms this solution would require building asubscription service and maintaining it, smaller firms may be able to use amanual system that could provide this sort of service fairly easily.8.13 PublishPolicy documents should be published so that they are available to all companyemployees. This usually means putting them on a company intranet site,possibly the information security team‟s own intranet site. The documents shouldbe easily accessible and available for download, printing, and saving.Determining the most appropriate policy delivery method is a particular issue for

large companies or those with large numbers of policies that don‟t apply to all employees. As already discussed in the communication strategy section, atailored system of policy delivery would mean that an employee would receivedirectly only those policies they needed to comply with to do their job. This wouldmake it much more likely that the employee will read and comply with the policyversus a conventional system where they have to seek out the relevant policiesfrom a larger policy bucket.8.14 Activate Communication StrategyEmail is probably the best way to inform employees about policy changes quicklyand effectively, although you may also want to include information about policy inother forms of company communication and through your company‟s security awareness program.Ensure policy is reflected in awareness strategies. An effective securityawareness strategy will ensure that all your audiences are aware of your securitypolicies, know where to find them and how to comply with them, as well as theconsequences of non-compliance. Through a security awareness program, itshould be possible to teach policy stakeholders about the policy and their role inmaintaining it. This will help make the policy an integral part of their jobs10.10 Barman, p.98.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.24It is through using communication and education programs that you will be betterable to foster a positive attitude in your company towards information security.There is evidence to show that users of the information security systems wouldbe more willing to adhere to better security practices if they were knowledgeable(i.e., better trained and better informed) about what good practice actuallyinvolved11.



A major part of ensuring policies have value is to ensure the employees who aresupposed to follow them are aware of them and perhaps even more importantly,are aware of the value of adhering to them. This can be a big cultural shift in anyorganization. People often say things like: “but we‟ve always done it that way” or “it doesn‟t matter if those SSNs go missing because we have stored them

elsewhere”. What security awareness campaigns must reflect is that the worldhas changed and it isn‟t about protecting the information just well enough so that it can be used for whatever purpose the company needs it for. There are nowlaws requiring companies to protect information at all times and to informcustomers where security breaches occur. Therefore it isn‟t enough just to do things as they have always been done or not to keep records of what customerinformation is stored where. This may have been enough previously, but whatyour security awareness campaigns need to reflect is that things have changedand the front line in ensuring information is protected are the employees. Onceemployees realize that even relatively small security breaches can havepotentially devastating (and job jeopardizing) consequences, they are much more

likely to be willing to act as your first line of defense and to pick up your policiesand start adhering to them. Awareness, education and policy go hand in hand,each strengthening the other.8.15 Regularly Review and UpdateEach policy document should be updated regularly. At a minimum, an annualreview strikes a good balance, ensuring that policy does not become out of datedue to changes in technology or implementation, but is more feasible than areview every six months which would require a very quick turnover of a largenumber of policies for a large company. There should also be a provision for adhoc updates that are necessary when fundamental changes in technology orprocess render existing policies, or parts of them, redundant.The review process should mirror the initial development process, but should beshorter, with the initial drafting phase telescoped into fewer meetings, or carriedout over email. The time for review phases by groups outside the informationsecurity team can also be shortened by having all groups review the draft at thesame time.When reviewing existing policies, a number of factors should be taken intoaccount in addition to those included during the initial development. Theexperience of working with the existing policy by users, systems administrators,or anyone else who has seen the policy in action is valuable here. These peopleshould be interviewed on how they think the policy worked and what could be11 JISC, p.3.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.25changed in the future. They will also provide valuable insights into changes intechnology or industry best practices that may need to be reflected by a changein the policy. Any security violations, deviations, and relevant audit information



should also be reviewed when reviewing existing policy12. This information willhighlight any areas where the policy was difficult to enforce or where frequentdeviations from policy were noted. It may be that elements of the policy areinfeasible or need to be tweaked slightly to ensure that extra and unnecessarywork on deviations is not created. This must as always be balanced with good

security practice. Policy must primarily reflect what is necessary for goodsecurity. From a due diligence viewpoint, it is not acceptable to change goodpolicy to inadequate policy just because there were a number of requests todeviate from that policy by certain groups within the company.12 Barman, p.132.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.269. Policy Document Outline

In addition to the policy statements that will form the main body of your policydocuments (see Appendices 1-2 for sample policy outlines), each policy shouldinclude the following sections.9.1 IntroductionThis section should introduce the policy by name and locate it within thehierarchy of other existing information security and company policy documents.9.2 PurposeState the main goals of the policy; this will explain the reason for the policy andwill help readers understand how the policy should be used. Legal andcompliance issues should also be mentioned in here. Include statements on anyspecific legislation the policy is designed to adhere to.9.3 ScopeThe scope is a statement of the infrastructure and information systems to whichthe policy applies, and the people who are stakeholders in it. Stakeholderswould typically include anyone who is a user of the information or systemscovered by the policy.9.4 Roles and ResponsibilitiesThis is a statement of the structures through which the responsibilities for policyimplementation are delegated throughout the company. Job roles may bespecified in this section, e.g., Database Administrators (DBAs), TechnicalCustodians, Field Office employees, etc.9.5 Sanctions and ViolationsThis section details to what extent breaking policy is considered a violation (e.g.,it is HR-related and therefore related to an employee‟s contract, or is it an information security department matter?) This section should also detail howviolations should be reported, who to and what actions should be taken in theevent of a violation. It should also include information on what sanctions will becarried out resulting from a violation (for example, verbal or written warnings,etc).9.6 Revisions and Updating Schedule



This section defines who is responsible for making updates and revisions to thepolicy and how often these will take place. It may be useful to include areference to the document as a “living document” which can be updated as determined by those responsible for updates and revisions. This will ensure thatany ad hoc revisions are accounted for as well as scheduled updates.

Information should also be included detailing where the policy will be publishedand how employees can access it. © SANS Institute 200 7, Author retains full rights.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.279.7 Contact informationDetail who should be contacted in connection with policy. A group or mailboxrather than an individual is preferable here as these are less likely to change.9.8 Definitions/Glossary

Define any terms that may be unfamiliar to the reader. The necessity for this willdepend on the audience, e.g., the readership of a Technical Policy for Linux arelikely to already be familiar with the Linux technical terms, therefore it will not benecessary to spell these out. The cryptography section of the user policyhowever may include terms with which readers are not familiar and these shouldbe defined in footnotes or a glossary to aid comprehension.9.9 AcronymsA separate section spelling out acronyms may be required where there are alarge number or where the document is long or complex. For shorter documents,acronyms may instead be spelt out in the body of the document.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.2810. TroubleshootingThis section details some of the things that go wrong during policy developmentand some ideas to remedy these problems.10.1 Policies Lack WeightIt is a big concern when policies that have taken time and effort to develop arenot taken seriously. This is common when starting to develop informationsecurity policies and for those whose development process isn‟t yet mature. Don‟t worry too much at these early stages. Weight is likely to come with time and increasing numbers of policies, backed up and promoted by a combination ofmanagement backing and a good awareness/communication campaign. Withthis will come a realisation on the part of the enterprise (and particularly thosebodies involved in compliance and governance) that policy can be used toleverage change and a move towards best practice and compliance.10.2 Lack of Reviewing FeedbackLack of feedback following reviews can also be a fairly common complaint from



the policy development team. This is fine if the reviewers have read the policyand simply don‟t have any feedback; the problem arises when they have skimmed over the document without reading it closely or taking in the implicationof its content. In these cases problems may only be noticed at a much laterstage or, even worse, after publication. This can serve to weaken the policy and

even discredit the policy development process as a whole.One solution is to review each document in detail at a meeting (or meetings) witheach group of reviewer. The development team representative can read througheach policy statement and seek feedback on each one. This will help make surethe reviewers have both read and thought about the policy in detail.Sometimes reviewers may not be sure what is required of them and this mayresult in a low level of feedback. To avoid this, inform all your reviewers aboutthe process and what is expected of them (e.g., you are looking for feedback onthe technical content of the policy rather than on typos and grammar errors).Another possible reason for this is simply not giving the reviewers enough time toreview. Be aware of their workload and agree a realistic timescale in advance. If

you are dealing with review groups regularly for more than one policy, agree aregular timescale and stick to this.10.3 Resources ShortageThis is frequently caused by two things: lack of management support andgenuine resource shortages due to high workloads and cost cuttings exercises.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.29If you really can‟t get access to those people you need to to write the policy, consider putting it on hold until the resources are available. Try managementyour plan and point out that the company will be without the policy until resourcescan be found. This may change their mind or they may decide that other thingstake priority.10.4 Reviews are Slow and CumbersomeSometime reviewing policy can seem to go for a long time. This can be becausethe project team size is too large. The optimum size for the core team is around3 people. 2-4 is fine but any more than 4 and you start to have to take a lotlonger to air everyone‟s views on each policy statement. If there are other people who are keen to be involved, keep the project team small but have theadditional people review the policy as external stakeholder in a review period oftheir own. This way not everyone has to be consulted every step of the way buteveryone still has an input.Another reason for slow reviews is that often no one wants to take responsibilityfor making a decision. This is particularly the case on more contentious issuessuch as whether to allow instant messaging for all employees or what kind ofmobile devices are allowed to be used. Reviews can often get stuck if no onewants to make the final decision. As always, take account of all opinions but trynot to let policy get stuck on this. Maybe make a softer policy statement in the



interests of getting something published. You might find in 6 months things havechanged and a decision can be reflected in a more strongly-worded updatedpolicy.10.5 Legislation Compliance QueriesHow do we know if we are complying with legislation? This is a commonly asked

question in relation to policy. To ensure compliance, it is important to use yourLegal and Compliance teams. Get their input on what is required and tie yourpolicy statements to specify legal or regulatory requirements.For larger companies, consider investing in a policy management system whichwill help you to track where your policies correlate with legislation and bestpractice.10.6 Policy is Quickly Out of DateIf your users are complaining that policy is out of date when it is published, takethis seriously. It is another issue that can quickly discredit your policydevelopment program.Reason for this include your review process being too slow (see section 7.4) or

that policy is too focused on current practice and future changes aren‟t considered during the development stages. Make sure to consult your reviewerson where they think security is heading in the future for a given technology or


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.30application. This will ensure this is reflected in policy as well as what happenstoday.10.7 Policy is UnclearIf people can‟t understand or interpret your policies, they are unlikely to complywith them. Indeed, policies shouldn‟t be open to interpretation; they should be clear and concise, with each statement having only one possible meaning. Toensure this is the case, use a style guide and the services of a technical writer oran editor for each policy. Make sure you have a proper final review process inplace where your policy is proof-read before being published. This should getrid of any last-minute typos or issues that will prevent comprehension.10.8 People get Upset by the New PolicyPeople don‟t like change. Especially when they have been doing something one way for a long time, they don‟t like to told that there are now new rules that say they have to do it differently – even if those new rules will make their lives easierin other ways once they‟ve got over the short term pain of making the changes. These are the simple reasons why there is often resistance to new and revisedpolicies. Some of the industry‟s most experienced security experts have encountered this phenomenon13 and it is something that you can expect tocontend with throughout the policy development process.Users will often have well-founded reasons for being concerned. They don‟t want to be bound by tight controls that make their job more difficult andmanagement are concerned by possible increased costs associated with putting



the policy into practice14. The best you can hope for here is to draw theirattention to the benefits of developing the policy and point out that you need theirhelp to do it properly and so that their fears aren‟t realized. Users and system support staff will often be concerned that the policy development team is going toforce policy upon them without any comeback and this can make them resistance

to participating in the development process. Be sure to fully explain your processto them at the start and make it clear that you need their input. Be firm, thispolicy is getting written, but you want to make sure it is workable and you wanttheir help to do this. You anticipate that once it is in place it will actually helpthem in their job role because it will give them a clear template for which controlsthey have to adhere to. See section 2.4 for more detail on this issue.Lastly, persevere. Initial reluctance can often give way to beneficial input andgood support later on.13 Guel, p.5.14 ibid.

© SANS Institute 200 7, Author retains full rights.

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.3111. ConclusionPolicy is both the starting point and the touchstone for information security in anycompany. Policy provides evidence of the company‟s stance on security and provides a living tool for every employee to help build and maintain that level ofsecurity. It is therefore essential that security policy is accurate, comprehensive,and useable. It can be a daunting task to produce policy that lives up to thisstandard. Assessing policy audiences, topics, and methods using the processesI have described in this paper will help to ensure that your policy documents areas efficient and useable as possible. In turn, this will help ensure that your effortsto raise the standard of security in your company are worthwhile.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.32ReferencesBarman, Scott. Writing Information Security Policies. New York: Que, 2001.Danchev, Dancho. “Building and Implementing a Successful information Security Policy.” 2003. URL: http://www.windowsecurity.com/pages/security-policy.pdf (10July 2006)Desilets, Gary. “Shelfware: How to Avoid Writing Security Policy andDocumentation That Doesn‟t Work.” 20 Apr. 2001. URL: http://www.giac.org/practical/gsec/Gary_Desilets_GSEC.pdf (10 July 2006)Guel, Michele D. “A Short Primer for Developing Security Policies.” 2001. URL: http://www.sans.org/resources/policies/Policy_Primer.pdf (12 July 2006)Harris, Shon, CISSP All in One Certification Exam Guide. New York: The



McGraw-Hill Companies, 2002.Jarmon, David. “A Preparation Guide to Information Security Policies.” 12 Mar. 2002. URL: http://www.sans.org/rr/paper.php?id=503 (10 July 2006)JISC, “Developing an Information Security Policy”, 1 May 2001. URL: http://www.jisc.ac.uk/index.cfm?name=pub_smbp_infosec (10 July 2006)

Kok Kee, Chaiw. “Security Policy Roadmap – Process for Creating SecurityPolicies.” 2 Oct. 2001. URL: http://www.sans.org/rr/paper.php?id=494 (10 July 2006)Lambe, Jennifer L. Intercom, “Techniques for successful SME interviews.” Mar. 2000, pp.30-32Lindley, Patrick J. “Technical Writing for IT Security Policies in Five Easy Steps.” 20 Sept. 2001. URL: http://www.sans.org/rr/paper.php?id=492 (10 July 2006)Long, Gerald P. “Security Policies in a Global Organization.” 25 Feb. 2002. URL: http://www.sans.org/rr/paper.php?id=501 (10 July 2006)Peltier, Thomas, R. “Information Security Fundamentals.” 2002. URL: http://www.gocsi.com/ip.htm (29 Sept. 2003)

© SANS Institute 200 7, Author retains full rights.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.33Russell, Chelsa. “Security Awareness – Implementing an Effective Strategy.” 25 Oct. 2002. URL: http://www.sans.org/rr/paper.php?id=418 (10 July 2006)“Best Practices – Security Plans and Policies.” URL:www.itsc.state.md.us/info/InternetSecurity/BestPractices/SecPolicy.htm (24 Sept2003)


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.34Appendix 1: Governing Policy OutlineThe outline below gives the broad topic headings for a sample Governing Policy.The sections outlined in the Policy Document Outline section of this paper shouldalso be included at the beginning of any Governing Policy.Many of these topics will be relevant to the information security of allorganizations, however some will vary according to the technology, systems, andapplications used.1. Responsibilities – Information Security and Audit Departments2. Email and Internet Use3. Ethics and Appropriate Use4. Personnel / Administration5. User Identification and Accountability6. Managing Users Accounts7. AuthenticationThis section might include statement like:



• User IDs and passwords must not be shared. • Passwords must not be written down. 8. Access Control9. AuthorizationThis section might include statements like:

• Authorization must only be granted to access company information and systems to the level required for a user‟s job role. • Authorization to access information and systems must be re-verified at aminimum annually.10. Auditing11. Physical12. Hardware13. Software14. Incident Response15. Intrusion Detection16. Cryptography

17. Data Classification © SANS Institute 200 7, Author retains full rights.Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.3518. System and Network ControlsIncluding software settings and system configuration and settings andpatching19. Business Continuity / Disaster Recovery20. Compliance Measurement21. Change Management22. Information HandlingIncluding printing, copying, faxing, mailing, emailing, etc23. Information Backup24. Remote Access25. Third Party / Service Provider Management26. Network ConnectionsIncluding internal and external and wireless27. Instant Messaging28. Web Conferencing29. Voice Communications30. Application DevelopmentEach section should detail what the company‟s stance is for each area in terms of the high-level requirements.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.36



Appendix 2: Technical Policy OutlineThe outline below gives the broad topic headings for a sample Technical Policyfor an operating system or an application. The sections outlined in the PolicyDocument Outline section of this paper should also be included at the beginningof any technical policy.

Many of these topics will be relevant to the security of all organizations, howeversome will vary according to the technology, systems, and applications used. Thelist below can be used to generate idea for policy statements in each area, but itisn‟t necessary to use all the categories in each case, sometimes they just won‟t apply.1. General Usage Requirements2. Authentication3. Authorization4. Auditing5. Network Services6. Physical Security

7. Operating System Security8. Business Continuity/Disaster Recovery9. Compliance MeasurementOther technical policies such as physical security or audit policies will includesome different types of information. The outline below gives the broad topicheadings for a sample Physical Security Technical Policy.1. General Requirements2. Authorization - Building Access(An example section with specific policy statements for inclusion under“Building Access” is detailed below) a. Emergency Exits• Emergency exits must be locked from the outside but not from the inside.• Emergency exits must be alarmed so that an alarm sounds when the exit is used.• Signs must be placed at each emergency exit to indicate thatthe exit is for emergency use only, and that an alarm will soundif the exit is used.• Exits and aisles must be unobstructed at all times.


© SANS Institute 2007, As part of the Information Security Reading Room Authorretains full rights.373. Controlled Area Access4. Equipment Protection5. Housekeeping6. Water Protection7. Fire Protection8. Air Conditioning and Electrical Power



9. MaintenanceLast Updated: March 12th, 2012Upcoming SANS TrainingClick Here for a full list of all Upcoming SANS Events by LocationSANS Abu Dhabi 2012 Abu Dhabi, United Arab

EmiratesMar 31, 2012 - Apr 05, 2012 Live EventSANS Northern Virginia 2012 Reston, VA Apr 15, 2012 - Apr 20, 2012 Live EventSANS Cyber Guardian 2012 Baltimore, MD Apr 30, 2012 - May 07, 2012 Live EventSANS Secure Europe 2012 Amsterdam, Netherlands May 05, 2012 - May 19, 2012 LiveEventSANS Security West 2012 San Diego, CA May 10, 2012 - May 18, 2012 Live EventSANS Toronto 2012 Toronto, ON May 14, 2012 - May 19, 2012 Live EventSANS Brisbane 2012 Brisbane, Australia May 21, 2012 - May 26, 2012 Live EventSANS Secure Indonesia 2012 Jakarta, Indonesia May 28, 2012 - Jun 02, 2012 LiveEvent

SANS Rocky Mountain 2012 Denver, CO Jun 04, 2012 - Jun 09, 2012 Live EventSANS 2012 OnlineFL Mar 23, 2012 - Mar 30, 2012 Live EventSANS OnDemand Books & MP3s Only Anytime Self Paced



2.12. To enable data to be recovered in the event of a virus outbreak regular backups willbe taken by the I.T. Department.

2.13. Management strongly endorse the Organisation's anti-virus policies and will make thenecessary resources available to implement them.

2.14. Users will be kept informed of current procedures and policies.2.15. Users will be notified of virus incidents.2.16. Employees will be accountable for any breaches of the Organisation's anti-virus

policies.2.17. Anti-virus policies and procedures will be reviewed regularly.2.18. In the event of a possible virus infection the user must inform the I.T. Department

immediately. The I.T. Department will then scan the infected machine and anyremovable media or other workstations to which the virus may have spread anderadicate it.




3. PHYSICAL SECURITY OF COMPUTER EQUIPMENTPhysical Security of computer equipment will comply with the guidelines as detailed below.

3.1. DEFINITIONS

3.1.1. AREATwo or more adjacent linked rooms which, for security purposes, cannot beadequately segregated in physical terms.

3.1.2. COMPUTER SUITEMainframe, minicomputer, fileserver plus all inter-connected wiring, fixed disks,telecommunication equipment, ancillary, peripheral and terminal equipment linkedinto the mainframe, contained within a purpose built computer suite.

3.1.3. COMPUTER EQUIPMENTAll computer equipment not contained within the COMPUTER SUITE which willinclude PC's, monitors, printers, disk drives, modems and associated and peripheralequipment.

3.1.4. HIGH RISK SITUATION(S)This refers to any room or AREA which is accessibleat ground floor levelat first floor level, but accessible from adjoining roofat any level via external fire escapes or other features providing accessrooms in remote, concealed or hidden areas

3.1.5. LOCKDOWN DEVICE(S)A combination of two metal plates, one for fixing to furniture, or the buildingstructure, and the other for restraining the equipment which is immobilised when thetwo plates are locked together. The plate for restraining the equipment shouldincorporate an enclosure or other mechanism which will hinder unauthorised

removal of the outer PC casing and render access to internal components difficult.3.1.6. APPROVEDPage 7 IT Security Policy



Approved security system.3.1.7. PERSONAL COMPUTERS (PC's)

Individual computer units with their own internal processing and storage capabilities.

3.2. CATEGORIES OF RISK

1: the security measures detailed in Level 1 are guidelines for all COMPUTER EQUIPMENT notdescribed below.2: these guidelines apply where a single room or AREA contains PC's where the total replacement

value of this hardware is LESS than 20,000 per room or AREA.3: these guidelines apply where a single room or AREA contains PC's where the total replacement

value of this hardware is between 20,000 and 50,000 per room or AREA.4: these guidelines apply where a single room or AREA contains PC's where the total replacement

value of this hardware is in excess of 50,000 per room or AREA.3.2.5. COMPUTER SUITEThese guidelines apply to the location or room comprising the purpose built computer suite.Page 8 IT Security Policy



3.3. REQUIRED PHYSICAL SECURITY

The table below summarises the required features for each Security Level. Security Level

No Security Features 1 2

1 Security Marking x x

2 Locking of PC cases x x

3 Siting of computersaway from windows

x x

4 HIGH RISKSITUATION windowlocks

x x

5 Blinds for observablewindows

x x

6 If no intruder alarm,all PC's andCOMPUTEREQUIPMENT >1,500, to have aLOCKDOWNDEVICE

x x

7 Intruder alarm installed byAPPROVED Company

x

8 Protection of signaltransmission to AlarmReceiving Centre

x

9 Assessment of location ofintruder alarm protection

x

10 Walk test of movementdetectors

x

11 Check that movementdetectors are not obscured

x

12 Anti-masking intruder alarmsensors in room or AREA x

13 Break glass alarm sensors x

14 Individual alarm zoning of theroom or AREA

x

15 Improved protection of signaltransmission to Alarm ReceivingCentre

x

16 Minimum room or AREAconstruction

x

17 Door specification for entry toroom or AREA

x

18 Anti-masking intruder alarm sensors in room

and access routes19 Alarm shunt lock on door

20 Visual or audio alarm confirmation

21 Superior protection of alarm signaltransmission

22 Improved room or AREA construction

23 All external opening windows to have locks

24 HIGH RISK SITUATION windows to haveshutters/bars



3. PHYSICAL SECURITY OF COMPUTER EQUIPMENTPhysical Security of computer equipment will comply with the guidelines as detailed below.

3.1. DEFINITIONS

3.1.1. AREATwo or more adjacent linked rooms which, for security purposes, cannot beadequately segregated in physical terms.

3.1.2. COMPUTER SUITEMainframe, minicomputer, fileserver plus all inter-connected wiring, fixed disks,telecommunication equipment, ancillary, peripheral and terminal equipment linkedinto the mainframe, contained within a purpose built computer suite.

3.1.3. COMPUTER EQUIPMENTAll computer equipment not contained within the COMPUTER SUITE which willinclude PC's, monitors, printers, disk drives, modems and associated and peripheralequipment.

3.1.4. HIGH RISK SITUATION(S)This refers to any room or AREA which is accessibleat ground floor levelat first floor level, but accessible from adjoining roofat any level via external fire escapes or other features providing accessrooms in remote, concealed or hidden areas

3.1.5. LOCKDOWN DEVICE(S)A combination of two metal plates, one for fixing to furniture, or the buildingstructure, and the other for restraining the equipment which is immobilised when thetwo plates are locked together. The plate for restraining the equipment shouldincorporate an enclosure or other mechanism which will hinder unauthorised

removal of the outer PC casing and render access to internal components difficult.3.1.6. APPROVEDPage 7 IT Security Policy



Approved security system.3.1.7. PERSONAL COMPUTERS (PC's)

Individual computer units with their own internal processing and storage capabilities.

3.2. CATEGORIES OF RISK

3.2.1. SECURITY LEVEL 1: the security measures detailed in Level 1 are guidelines for allCOMPUTER EQUIPMENT not described below.3.2.2. SECURITY LEVEL 2: these guidelines apply where a single room or AREA contains

PC's where the total replacement value of this hardwareis LESS than 20,000 per room or AREA.

3.2.3. SECURITY LEVEL 3: these guidelines apply where a single room or AREA containsPC's where the total replacement value of this hardwareis between 20,000 and 50,000 per room or AREA.

3.2.4. SECURITY LEVEL 4: these guidelines apply where a single room or AREA containsPC's where the total replacement value of this hardwareis in excess of 50,000 per room or AREA.

3.2.5. COMPUTER SUITE

These guidelines apply to the location or room comprising the purpose built computer suite.Page 8 IT Security Policy



3.3. REQUIRED PHYSICAL SECURITY

The table below summarises the required features for each Security Level. Security Level

No Security Features 1 2

1 Security Marking x x

2 Locking of PC cases x x

3 Siting of computersaway from windows

x x

4 HIGH RISKSITUATION windowlocks

x x

5 Blinds for observablewindows

x x

6 If no intruder alarm,all PC's andCOMPUTEREQUIPMENT >1,500, to have aLOCKDOWNDEVICE

x x

7 Intruder alarm installed byAPPROVED Company

x

8 Protection of signaltransmission to AlarmReceiving Centre

x

9 Assessment of location ofintruder alarm protection

x

10 Walk test of movementdetectors

x

11 Check that movementdetectors are not obscured

x

12 Anti-masking intruder alarmsensors in room or AREA x

13 Break glass alarm sensors x

14 Individual alarm zoning of theroom or AREA

x

15 Improved protection of signaltransmission to Alarm ReceivingCentre

x

16 Minimum room or AREAconstruction

x

17 Door specification for entry toroom or AREA

x

18 Anti-masking intruder alarm sensors in room

and access routes19 Alarm shunt lock on door

20 Visual or audio alarm confirmation

21 Superior protection of alarm signaltransmission

22 Improved room or AREA construction

23 All external opening windows to have locks

24 HIGH RISK SITUATION windows to haveshutters/bars

Uganda It Policy

Documents

Transcript of Uganda It Policy