Ministry of Education and Science of the Republic of

Kazakhstan
Al-Farabi Kazakh National University

Report
Administrative security.
by discipline «Information Security Management in industrial information systems»

Faculty: "Information Technology"

Department: "Information Systems"

Done by: Mukasheva Akbota

Checked by: associate professor Azanov N.P

Almaty, 2022
 Introduction
The main purpose of the administrative level measures is to form a program
of work in the field of information security and ensure its implementation,
allocating the necessary resources and monitoring the state of affairs.
The main purpose of the administrative level measures is to form a program
of work in the field of information security and ensure its implementation,
allocating the necessary resources and monitoring the state of affairs.
The basis of the program is a security policy that reflects the organization's
approach to protecting its information assets. The management of each
organization should realize the need to maintain a security regime and allocate
significant resources for this purpose.
The security policy is based on the analysis of risks that are recognized as real
for the organization's information system. When the risks are analyzed and the
protection strategy is defined, an information security program is compiled.
Resources are allocated for this program, responsible persons are appointed, the
procedure for monitoring the implementation of the program is determined, etc.
The term "security policy" is not an exact translation of the English phrase
"security policy", but in this case the tracing paper better reflects the meaning of
this concept than the linguistically more correct "security rules". We will not be
referring to individual rules or sets of them (such decisions are made at the
procedural level, which we are talking about ahead), but the organization's strategy
in the field of information security. Undoubtedly, political decisions taken at the
highest level are needed to develop a strategy and implement it.
The IP of an organization and the interests of its subjects associated with it is
a complex system, for consideration of which it is necessary to apply an object—
oriented approach and the concept of the level of detail. It is advisable to identify
at least three such levels, which we have already done in the example and will do
again later.
In order to consider IP in a substantive way, using up-to-date data, it is
necessary to make a map of the information system. This map, of course, must be
made in an object-oriented style, with the ability to vary not only the level of
detail, but also the visible faces of objects. A freely distributed framework of a
control system can serve as a technical means of compiling, maintaining and
visualizing such maps.
Top-level Security Policy
From a practical point of view, it is advisable to consider security policy at
three levels of detail. Decisions affecting the organization as a whole can be
attributed to the upper level. They are very general in nature and, as a rule, come
from the management of the organization. An approximate list of such solutions
may include the following elements:
 the decision to form or revise a comprehensive information security
program, the appointment of those responsible for the promotion of the
program;
 formulation of the goals pursued by the organization in the field of
information security, definition of general directions in achieving these
goals;
 providing a framework for compliance with laws and regulations;
 formulation of administrative decisions on those issues of the
implementation of the security program that should be considered at the
level of the organization as a whole.
For top-level policy, the organization's information security goals are
formulated in terms of integrity, accessibility, and confidentiality. If an
organization is responsible for maintaining critical databases, reducing the number
of data losses, damages or distortions may be in the foreground. For an
organization engaged in the sale of computer equipment, it is probably important
to keep up-to-date information about the services and prices provided and its
availability to the maximum number of potential buyers. The management of a
regime enterprise primarily cares about protection from unauthorized access, that
is, about confidentiality.
The management of protective resources and coordination of the use of these
resources, the allocation of special personnel to protect critical systems and
interaction with other organizations that provide or control the security regime are
placed at the top level.
Top-level policy should clearly outline its sphere of influence. Perhaps it will
be all the computer systems of the organization (or even more, if the policy
regulates some aspects of the use of employees of their home computers).
However, it is also possible that only the most important systems are included in
the sphere of influence.
The policy should define the responsibilities of officials to develop a security
program and implement it. In this sense, the security policy is the basis for staff
accountability.
Top-level policy deals with three aspects of law-abiding and performance
discipline. First, the organization must comply with existing laws. Secondly, the
actions of those responsible for the development of the security program should be
monitored. Finally, it is necessary to ensure a certain degree of performance of the
staff, and for this it is necessary to develop a system of rewards and punishments.
 Generally speaking, a minimum of questions should be brought to the upper
level. Such a decision is advisable when it promises significant cost savings or
when it is simply impossible to do otherwise.
The British standard BS 7799:1995 recommends that the following sections
be included in the document describing the organization's security policy:
· introductory, confirming the concern of senior management about
information security issues;
· organizational, containing a description of departments, commissions,
groups, etc., responsible for work in the field of information security;
· classification, describing the material and information resources available in
the organization and the necessary level of their protection;
· regular, characterizing the security measures applied to personnel (job
descriptions from the point of view of information security, organization of
training and retraining of personnel, the procedure for responding to security
violations, etc.);
· section covering physical protection issues;
· management section describing the approach to managing computers and
computer networks;
· a section describing the rules for delimiting access to production
information;
· a section describing the procedure for developing and maintaining systems;
· a section describing measures aimed at ensuring the continuous operation of
the organization;
· a legal section confirming the compliance of the security policy with the
current legislation.
The average level includes issues related to certain aspects of information
security, but important for various systems operated by the organization. Examples
of such issues are the attitude to advanced (but perhaps insufficiently proven)
technologies, Internet access (how to combine freedom of access to information
with protection from external threats?), the use of home computers, the use of
unofficial software by users, etc.
The middle-level policy should cover the following topics for each aspect:
 Description of the aspect. For example, if we consider the use of
unofficial software by users, the latter can be defined as software that
has not been approved and/or purchased at the organization level.
  The organization's position on this aspect. Continuing the example with
unofficial software, one can imagine the positions of a complete ban,
the development of a procedure for the acceptance of such software,
etc. The position can also be formulated in a much more general way,
as a set of goals that the organization pursues in this aspect. In general,
the style of documents defining the security policy (as well as their list)
may vary greatly in different organizations.
 Roles and responsibilities. The "political" document should include
information about the officials responsible for the implementation of
the security policy. For example, if employees need management
permission to use unofficial software, they should know from whom
and how to get it. If unofficial software cannot be used, you should
know who is monitoring the implementation of this rule.
 Law-abiding. The policy should contain a general description of
prohibited actions and penalties for them.
 Points of contact. It should be known where to apply for explanations,
assistance and additional information. Usually, the "point of contact" is
a certain official, and not a specific person who currently holds this
post.
Lower-level security policy
The lower-level security policy refers to specific information services. It
includes two aspects — goals and rules for achieving them, so it is sometimes
difficult to separate it from implementation issues. Unlike the top two levels, the
policy in question should be defined in more detail. There are many things specific
to certain types of services that cannot be regulated in a single way throughout the
organization. At the same time, these things are so important for ensuring the
security regime that decisions related to them should be made at the managerial,
not technical level. Here are some examples of questions that should be answered
in the lower-level security policy:
· who has the right to access the objects supported by the service?
· under what conditions can the data be read and modified?
· how is remote access to the service organized?
When formulating the goals of the lower-level policy, one can proceed from
considerations of integrity, accessibility and confidentiality, but one cannot stop
there. Its goals should be more specific. For example, if we are talking about a
payroll system, we can set a goal that only employees of the personnel department
and accounting department are allowed to enter and modify information. More
generally, goals should link service objects and actions with them.
 Security rules are derived from the goals, describing who can do what and
under what conditions. The more detailed the rules are, the more formally they are
set out, the easier it is to support their implementation with software and hardware.
On the other hand, too strict rules can interfere with the work of users, and they
will probably have to be revised frequently. Management will have to find a
reasonable compromise, when an acceptable level of security will be provided for
an acceptable price, and employees will not be overly connected. Usually, access
rights to objects are most formally set due to the special importance of this issue.
After the security policy is formulated, you can start drawing up a program
for its implementation and actually implementing it.
To understand and implement a program, it needs to be structured by levels,
usually in accordance with the structure of the organization. In the simplest and
most common case, two levels are sufficient — the upper, or central, which covers
the entire organization, and the lower, or service, which refers to individual
services or groups of homogeneous services.
The top-level program is headed by the person responsible for the information
security of the organization. This program has the following main goals:
· risk management (risk assessment, selection of effective means of
protection);
· coordination of information security activities, replenishment and allocation
of resources;
· strategic planning;
· control of information security activities.
Within the framework of the top-level program, strategic decisions are made
to ensure security, technological innovations are evaluated. Information
technologies are developing very quickly, and it is necessary to have a clear policy
of tracking and implementing new tools.
The control of security activities has a two-way orientation. First, it is
necessary to ensure that the actions of the organization do not contradict the laws.
At the same time, contacts should be maintained with external regulatory
organizations. Secondly, it is necessary to constantly monitor the state of security
within the organization, respond to cases of violations and refine protective
measures taking into account changes in the situation.
It should be emphasized that the top-level program should occupy a strictly
defined place in the organization's activities, it should be officially accepted and
supported by management, as well as have a certain staff and budget.
 The goal of the lower—level program is to provide reliable and cost-effective
protection of a particular service or a group of homogeneous services. At this level,
it is decided which protection mechanisms should be used; technical means are
purchased and installed; day-to-day administration is performed; the state of
weaknesses is monitored, etc. Usually service administrators are responsible for
the lower-level program.
Synchronization of the security program with the life cycle of systems
If you synchronize the lower-level security program with the lifecycle of the
protected service, you can achieve a greater effect with less cost. Programmers
know that adding a new feature to a ready-made system is an order of magnitude
more difficult than initially designing and implementing it. The same is true for
information security.
The following stages can be distinguished in the life cycle of an information
service:
Initiation. At this stage, the need to purchase a new service is identified, its
intended purpose is documented.
Purchase. At this stage, specifications are being drawn up, acquisition options
are being worked out, and the actual purchase is being carried out.
Installation. The service is installed, configured, tested and put into operation.
Exploitation. At this stage, the service not only works and is administered, but
also undergoes modifications.
Decommissioning. There is a transition to a new service.
At the initiation stage, an understanding is formed that it is necessary to
purchase a new or significantly modernize an existing service; it is determined
what characteristics and what functionality it should have; financial and other
limitations are assessed.
From the point of view of security, the most important action here is to assess
the criticality of both the service itself and the information that will be processed
with its help. It is required to formulate answers to the following questions:
· what kind of information is intended to be served by the new service?
· what are the possible consequences of violating the confidentiality, integrity
and availability of this information?
· what are the threats to which the service and information will be most
vulnerable?
 · are there any features of the new service (for example, the territorial
distribution of components) that require special procedural measures?
· what are the characteristics of the personnel related to security
(qualifications, reliability)?
· what are the legal provisions and internal rules that the new service must
comply with?
The results of the criticality assessment are the starting point in drawing up
specifications. In addition, they determine the degree of attention that the
organization's security service should pay to the new service at subsequent stages
of its life cycle.
The procurement stage is one of the most difficult. It is necessary to finally
formulate the requirements for the protective means of the new service, for the
company that can claim to be a supplier, and for the qualifications that the
personnel using or servicing the purchased product should have. All this
information is made out in the form of a specification, which includes not only
equipment and programs, but also documentation, maintenance, and personnel
training. Of course, special attention should be paid to the compatibility of the new
service with the existing configuration. We also emphasize that security tools are
often optional components of commercial products, and it is necessary to make
sure that the relevant items do not fall out of the specification.
When the product is purchased, it must be installed. Despite the apparent
simplicity, installation is a very responsible matter. First, the new product should
be configured. Typically, commercial products come with security features
disabled; they need to be enabled and properly configured. For a large organization
with a lot of users and data, the initial setup can be very time-consuming and
responsible.
Secondly, the new service needs procedural regulators. It is necessary to take
care of the cleanliness and security of the premises, the documents regulating the
use of the service, the preparation of emergency plans, the organization of user
training, etc.
After taking these measures, it is necessary to conduct testing. Its
completeness and complexity can serve as a guarantee of safe operation in normal
mode.
The period of operation is the longest and most difficult. From a
psychological point of view, the greatest danger at this time is minor changes in
the configuration of the service, in the behavior of users and administrators. If
security is not maintained, it weakens. Users do not so zealously follow job
descriptions, administrators analyze registration information less carefully. One or
the other user gets additional privileges. It seems that nothing has changed in
essence; in fact, there is no trace of the former security left.
To combat the effect of slow changes, we have to resort to periodic security
checks of the service. Of course, after significant modifications, such checks are
mandatory.
During decommissioning, the hardware and software components of the
service and the data processed by it are affected. The equipment is sold, disposed
of or discarded. Only in specific cases it is necessary to take care of the physical
destruction of hardware components that store confidential information. The
programs are probably simply erased, unless otherwise provided by the license
agreement.
When data is decommissioned, it is usually transferred to another system,
archived, discarded or destroyed. If archiving is performed with the intention of
subsequently reading the data in another place, care should be taken about the
hardware and software compatibility of reading and writing tools. Information
technologies are developing very quickly, and in a few years there may simply be
no devices capable of reading old media. If the data is archived in encrypted form,
it is necessary to save the key and decryption tools. When archiving and storing
archived information, we must not forget about maintaining data confidentiality.
Risk management is considered at the administrative level of information
security, since only the management of the organization is able to allocate the
necessary resources, initiate and monitor the implementation of relevant programs.
Risk management, as well as the development of its own security policy, is
relevant only for those organizations whose information systems and/or processed
data can be considered non-standard. An ordinary organization will be quite
satisfied with a typical set of protective measures chosen on the basis of an idea of
typical risks or without any risk analysis at all. When the possible damage is
unacceptably large, it is necessary to take economically justified protective
measures. Periodic risk assessment is necessary to monitor the effectiveness of
security activities and to take into account changes in the situation.
From a quantitative point of view, the level of risk is a function of the
probability of the realization of a certain threat (using some vulnerabilities), as well
as the magnitude of possible damage.
Thus, the essence of risk management measures is to assess their size, develop
effective and cost-effective risk mitigation measures, and then make sure that the
risks are contained within an acceptable framework (and remain so). Therefore,
risk management includes two types of activities that alternate cyclically:
· risk assessment (measurement);
 · selection of effective and economical protective means (risk neutralization).
In relation to the identified risks, the following actions are possible:
· elimination of risk (for example, by eliminating the cause);
· risk reduction (e.g. through the use of additional protective equipment);
· risk taking (and developing an action plan in appropriate circumstances);
· redirection of risk (for example, by concluding an insurance agreement).
The risk management process can be divided into the following stages:
1. Selection of the analyzed objects and the level of detail of their
consideration.
2. Choice of risk assessment methodology.
3. Identification of assets.
4. Analysis of threats and their consequences, identification of vulnerabilities
in protection.
5. Risk assessment.
6. The choice of protective measures.
7. Implementation and verification of selected measures.
8. Assessment of residual risk.
Risk management is a cyclical process. Risks need to be monitored
constantly, periodically reassessing them. Risk management, like any other activity
in the field of information security, must be integrated into the life cycle of the IP.
The selection of the analyzed objects and the level of detail of their
consideration is the first step in risk assessment. For a small organization, it is
acceptable to consider the entire information infrastructure; however, if the
organization is large, a comprehensive assessment may require unacceptable time
and effort. In this case, you should focus on the most important services, agreeing
in advance with the approximation of the final assessment.
It is very important to choose a reasonable risk assessment methodology. The
purpose of the assessment is to get an answer to two questions: are the existing
risks acceptable, and if not, what protective measures should be used. Risk
management is a typical optimization task. The fundamental difficulty lies in the
inaccuracy of the initial data. In the simplest and quite acceptable case, you can use
a three-point scale.
 When identifying assets, it is necessary to take into account not only the
components of the information system, but also the supporting infrastructure,
personnel, as well as intangible values, such as the reputation of the organization.
The starting point here is an idea of the mission of the organization, that is, about
the main areas of activity that it is desirable to preserve in any case. One of the
main results of the asset identification process is to obtain a detailed information
structure of the organization and how to use it. It is advisable to put this
information on the IP map as the faces of the corresponding objects.
Analysis of threats and their consequences, identification of vulnerabilities in
protection. The first step in analyzing threats is their identification. It is advisable
to identify not only the threats themselves, but also the sources of their occurrence
— this will help in choosing additional means of protection. For example, an
illegal login may result from playing the initial dialog, selecting a password, or
connecting unauthorized equipment to the network. Obviously, to counteract each
of the listed methods of illegal entry, we need our own security mechanisms.
Risk assessment. After identifying the threat, it is necessary to assess the
probability of its implementation (for example, on a three—point scale - low (1),
medium (2) and high (3) probability). In addition to the probability of
implementation, the size of the potential damage is important. For example, fires
are infrequent, but the damage from each of them is usually great. The severity of
the damage can also be assessed on a three-point scale.
It is quite acceptable to use such a method as multiplying the probability of a
threat by the alleged damage. If a three-point scale is used for probability and
damage, then there will be six possible products: 1, 2, 3, 4, 6 and 9. The first two
results can be attributed to low risk, the third and fourth to medium, the last two to
high, after which it becomes possible to bring them back to a three—point scale. It
is on this scale that the acceptability of risks should be assessed.
Literatures:
1. Gryaznov E.S., Panasenko S.A. Security of local networks. — M.:
University textbook, 2006.- 525 p.
2. Kozlachkov P.S. The main directions of development of information
security systems. — M.: finance and statistics, 2004.- 736 p.3. Levakov G.N.
Anatomy of information security. — M.: TK Velbi, Prospect publishing house,
2004.- 256 p.
4. The guidance document of computer technology. Protection against
unauthorized access to information. Indicators of security against unauthorized
access to information from March 30, 1992
 5. Silayenkov A.N. Designing an information security system: textbook.
manual — Omsk: Publishing house of OmSTU, 2009. — 128 p.
6. Sokolov D.N., Stepanyuk A.D. Protection from computer terrorism. —
Moscow: BHV-Petersburg, Arlit, 2002. - 456 p.
7. Sych O.S. Comprehensive antivirus protection of a local network. — M.:
Finance and statistics, 2006.- 736 p.
8. Shvetsova N.D. Technical safety systems: current realities. — St.
Petersburg: Peter, 2004. — 340 p.