Cyber security into practice¶

In this section, practice is not yet about daily tasks, but mainly refers to the terminology that cybersecurity practices consist of. You will need all of these in the later modules. After naming the security measures, we introduce policies to guide their selection and use. The we remind that security measures are needed because of threats. Finally, we introduce the handling of threats through risk management.

Means of cyber security¶

Cyber security is made with security controls or security measures. Some measures focus on preventing undesirable outcomes, while others aim to detect events that lead to such outcomes, and still others react to what has been detected. The selection of security measures is part of risk management processes.

Security control is one of many terms used in connection with security measures. Below is a list roughly ordered from the most general to the most specific. Note that the word security can be omitted when the context allows. The last two terms are the least commonly used. A security provider, “protector”, is already an implementation of a “service”, but the term security service may appear in a rather abstract sense.

safeguard,
security control,
security mechanism,
protection,
security measure; countermeasure,
security service,
security provider

When implementing security measures, it is important to consider whether they are appropriate and whether they achieve the desired effects. These are examined through security evaluation, which provides (security) assurance. The evaluation includes, for example, residual risk analysis, in which vulnerabilities are assessed after mitigation measures and it is decided whether they can be accepted.

Security policies¶

When you start at a new workplace, you first have to familiarize yourself with various rules. Security policy is one of them and you have to adapt to and adopt various security measures in your daily work. There are many types of policies. It is important to understand this main division:

General organisational rules that define how resources are protected.
Rules automatically enforced by IT systems regarding access to resources (see the core concepts of access control).

Sometimes, and now here, the terms organisational policies and automated policies are used to distinguish these.

Information security mechanisms should not be deployed for their own sake; there must be an application that requires protection. Organisational policy outlines the security requirements, and automated policy implements them. Sometimes this process can be straightforward and begin with a clearly defined organisational policy, for example one governing access to classified paper documents. Often, however, translation and interpretation are needed when deriving automated policies from organisational policies. All translations begin with a source document, which in this case is the organisational policy written in natural language. The target is the automated policy, examples of which include firewall rules and access control lists, each with their own technical languages.

Problems arise in translation if the source is unclear or inconsistent. This is more likely in matrix organisations, where multiple parties define policies, than in strictly hierarchical organisations. In addition, the greater the difference between the source and target languages, the more difficult the translation and the harder it is to ensure that it reflects the “spirit” of the source. This is a prerequisite for accepting the automated policy.

Organisational policies may deliberately leave decisions to case-by-case discretion. This is necessary, for example, in situations where no existing rule applies directly or where multiple slightly different rules concern the same matter. Automation removes this discretion. Consider, for example, the automation of almost any customer service situation.

Removing discretion may lead to rules that have no direct counterpart in the organisational policy. In such cases, creating automated policies becomes more than translation—it becomes “creative writing” in the spirit of the organisational policy. To succeed, the author must have a good understanding of applications and their workflows, in addition to mastery of the target language. Automated policies based on naive assumptions can easily become service-denying “attacks” against users. Automated policies should be kept simple, but at the same time they should cover a wide range of contexts in which rules are applied. As a result, the number of rules designed for exceptional situations often grows large. Both organisational and automated policies require dynamic handling of changes and analysis of rule side effects in systems that may be highly complex.

Regardless of how information security policy is structured, it is, as a whole, a documentation of decisions that defines who has access to which resources, how access is regulated, who is responsible, and what actions are taken in case of violations. Instead of the two-level structure described above, one may use the three categories introduced in the NIST handbook (NIST SP 800-12 Rev. 1), which are intended to enhance understanding rather than define strict boundaries:

information security strategy: the organisation’s objectives regarding information security and general responsibilities. The policy should also express the organisation’s commitment to security. An example of a general-level policy is the information security policy of Tampere University.
issue-specific policy, for example covering areas such as Internet access (who, for what purposes, with what authentication), email privacy issues (within the organisation), or the use of unofficial software or personal devices.
system-specific policy, where the system may be, for example, a computer network such as a software company’s test network or an industrial automation network. The policy consists of security objectives and operational security rules.

The information security strategy belongs to the organisational policy level, which also includes part of both issue-specific and system-specific policies, which at their most detailed level are best implemented as automated policies.

An example of objectives set in issue- or system-specific policies could be that salary information may only be processed by accounting and human resources staff. Derived rules might define which data fields each employee in these departments may edit, and that no one may edit their own data. At this level, implementation typically takes place automatically through access control rules. These may be supplemented by guidelines and procedures intended for employees to adopt. One example of security rules is the lists implemented in firewalls specifying which packets are allowed through and which are discarded.

Failures and security incidents¶

Cyber security enables the proactive management of various cyber threats and, when necessary, the tolerance of their impacts. This includes protection against an attacker or, for example, a physical or random process. An adversary, in this broad sense, can therefore be something other than a human.

When analysing security, adversaries can be modelled. Models examine different possibilities regarding what motivates adversaries, what kind of threat they pose, and what capabilities and means they have at their disposal. Naturally, one also needs to analyze the vulnerabilities that an adversary can exploit and which therefore form the attack surface.

When adversaries succeed, it may be concluded that security measures have failed, or alternatively that they were insufficient. When they do not achieve the desired effect or are lacking, the defence fails and a security incident occurs. These are often described based on the damage they cause. For example, theft or destruction causes damage that may affect information, devices, services, or networks. In cyber-physical systems, damage may also extend physically to people. An important part of security operations is detecting failures and responding to them.

A recurring theme in security analysis is that security measures are insufficient if they are designed only with a specific situation or framework in mind. One must also consider what happens if an adversary operates outside the assumed scenarios. Examples include side-channel attacks. An adversary may, for example, obtain information by monitoring emissions from a data cable without needing physical access to it. Another example is determining a cryptographic key by analysing a processor’s power consumption while it uses the key. Inadequate adversary modelling exists at all system levels. For example, it may be assumed that employees follow instructions, even though this is not always the case, and many planned security measures may lose their effectiveness.

These problems arise because system design requires abstractions and simplifications. This leaves gaps between details that adversaries can exploit. For example, in a networked system it is very difficult to account for all possible details starting from the physical characteristics of devices. Often, security measures are also based on these simplifications and therefore do not cover all possible situations. Adversaries, however, are not constrained by abstractions or simplifications and may attack from outside the assumed conditions. For example, systems are often abstracted into layers, such as in computer networks, and security measures may target a single layer. However, an adversary can attack that layer via a lower layer, thereby bypassing the protections implemented at that layer.

Risk¶

In business, risk is often defined as a combination of adverse events and their consequences. Risk management is the systematic identification of significant adverse events and preparation for them. In the risk management process, risks are first identified and their magnitude assessed. After that, measures to address them are planned. In addition, plans are made for responding to damage and recovering from it.

When assessing the magnitude of a risk, both the potential damage and its probability are considered. Probability has two factors: vulnerabilities—both known and unknown—and possible threats—those exploiting vulnerabilities and others.

In principle, unlimited time and money could be spent on risk management. In practice, however, resources are always limited, so judgement must be exercised. Typically, risks are prioritised, meaning only the most important ones are addressed, at least initially. There is also some choice in how risks are handled. Risks can be addressed with new or improved security measures that reduce either their impact or the likelihood of threats. Some of the risk can be transferred to others, for example by taking insurance. Activities can (sometimes) be changed so that the risk is removed. It is also possible to decide to do nothing and accept the risk. Risk management is discussed extensively in the next module.