Direkt zum Inhalt

Part 2 – An overview of data security

3 Data security: An Overview

3.1 Important concepts

Security is an integral part of everyday life, given the progress of globalisation, growing mobility and increasing importance of (or even dependence on) information and technology. Increased vulnerabilities and substantial financial losses as a result of IT security deficits are common. Actions that seek to minimise the prevailing risks and prevent the resulting damage are therefore of increased importance. An active security management process should be part of the general management process; such an approach is mirrored in various laws and regulations that organizations have to follow.

It is widely accepted that the implementation of the necessary IT security safeguards comes with a high investment and requires highly skilled personnel. However, the success of many (national and international) standards, guidelines and supporting information prove, that well-understood processes accompanied by well-informed, autonomous, and expert staff can achieve very good results. Effective measures in IT security, with the correct use of robust open source software, can be implemented at an affordable level regardless of the size of the organization.

Important but often underrepresented is the fact that IT security is not a static condition. In addition to setting up safeguards in order to protect IT systems it is necessary to analyse and evaluate the impact and effectiveness of the installed safeguards on security on a regular basis. This includes calculating the remaining risks and implementing additional measures in order to close any security gaps found. Usually, this is done by the development of different threat scenarios as well as evaluating their consequences and probabilities of occurrence. Typical scenarios could be:

  • What would happen if confidential information became available to third parties?
  • What would happen if there was undetected tampering of the information by third parties?

The successful implementation and operation of a well-working IT security management system can benefit organisations in multiple ways. The analysis and documentation of the underlying processes allows getting a better and clearer view on the business, which can lead to more reliable and higher quality work. In addition, successfully implemented IT security can result in higher trust from customers and end users.

According to the basics of IT security the following three fundamental CIA values characterise the field:

  • Confidentiality – describes the need to protect information against unauthorized access and disclosure.
  • Integrity – considers the aspects of unwanted modification and of authenticity[1] of the provided information.
  • Availability – describes the required level, the information and services that should be available to the users.

Figure 2: The three fundamental values of the IT security

The following sections will introduce the most important aspects of IT security and give a short description on each one of these aspects.

 

3.2 Data security aspects

In order to introduce the most important aspects of the IT security, six groups have been identified and will be described in the following subsections. The identified groups are:

  1. Security architecture design and operation
  2. IT-Systems security
  3. Communications
  4. The human factor
  5. IT-Systems maintenance
  6. Security policies

Each security aspect is numbered using the R-### pattern. A general description for each aspect can be found in the following subsections.

Not all security aspects are relevant to all data sharing building blocks. Section 4 details which security aspect is relevant to what data sharing building block and how these aspects are applied to their respective building blocks.

 

3.2.1 Security architecture design and operation

R-101

IT security aspects must be adequately considered early on in the project lifetime.

When designing the architecture, the policies and procedures of a product or service, security should be a priority in the design process rather than an afterthought or an add-on. More often than not, security mechanisms and policies belong to a crosscutting section of the overall design and, therefore, need to be considered at the start of the high-level design.

This approach is referred to as “security by design” and aims to produce services and products that are robust against the ever-increasing number of threats that even isolated systems are exposed to. Especially in a data-sharing environment, at least some of the services are bound to be exposed to the internet, or at least available remotely, which makes the whole system open to abuse by adversaries.

As stated in the OWASP “Security by design principles” [OWASP_SDP], “Applications without security architecture are as bridges constructed without finite element analysis and wind tunnel testing. Sure, they look like bridges, but they will fall down at the first flutter of a butterfly’s wings. The need for application security in the form of security architecture is every bit as great as in building or bridge construction”.

 

R-102

Alternative approaches should be considered when necessary resources are limited.

Implementation of security mechanisms and/or policies always comes at a cost. This can be the cost of procurement of specialized software and hardware, the cost of development and integration of custom solutions into the system, and the cost of operating and maintaining those mechanisms. Finding a compromise between available funds and costs of implementing security measures is key.

Since no project comes with an unlimited budget, in practice every security architect will face the challenge of keeping the result cost effective without compromising on the basic security principles that have been put into place during the early design steps.

While the basic security requirements must be fulfilled, the actual implementation of the mechanisms that fulfil those requirements are subject to cost-benefit analyses. As a result of such analyses, it is possible to come up with alternative solutions that can achieve the same level of security but at different costs. Usually, those alternatives have trade-offs in terms of usability, support or brand trust, and, more often than not, might incur unforeseen costs in the future. One example that warrants careful consideration of the alternatives is the use of open-source software. While there are excellent security products that are open-source and free for even commercial use, there is always the risk of those projects ceasing development or unforeseen costs of adoption due to lack of required APIs or documentation.

 

R-103

IT security requirements must be clearly specified.

The basis for the design and implementation of the security architecture of a service or a product are the requirements of that service/product. A number of requirements fit into almost all software products that are exposed to public networks (the most common scenario in a system that supports data sharing). However, the granularity and strictness of those requirements can vary widely depending on factors such as the nature of the data or the attack surface of the product. For example, open data usually does not come with the strict privacy requirements that personal data has. Likewise, systems deployed in computer emergency response teams (CERTs) have more physical security requirements than an SME’s advertisement publication services.

Therefore, the definition of security requirements needs to be both complete and precise in terms of granularity and scope. This safeguards against vulnerable implementations that are fulfilling the requirements only in contractual terms and against unexpected cost increases.

 

R-104

Appropriate controls should be implemented for every security requirement and associated mechanism.

Like software testing the implementation of a security mechanism that fulfils a given requirement should always be verifiable. Hence, appropriate controls should be implemented to allow for the quick verification of the correct fulfilment of the security requirements (e.g. all external communications should be encrypted).

Those controls can be either automatic or manual. Some examples of automatic controls include regular network scanning for unauthorized communications and regular automatic penetration tests. Manual audits should also be part of the standard operational procedures.

 

R-105

Full security management should be a long-term objective.

Apart from a suitable security architecture design and implementation, the correct operation and maintenance of the implemented system is of equal importance. Therefore, these operational procedures should be part of a full security management plan that includes classification of the system components and possibly the organization’s assets, as well as threat assessment and risk management.

A valuable tool for this task is a well-defined and enforced set of security policies. More details can be found in section 3.2.6.

 

R-106

Security mechanisms should be selected according to the relevant requirements.

A usual caveat during the design of a secure system is the selection of security mechanisms only based on the past experience of the organization or the level of experience of the architect, without the careful consideration whether those mechanisms are sufficient or necessary given the specific needs and requirements of the product.

This practice can either lead to the under-fulfilment of the security requirements or to an unnecessary complexity of the resulting architecture. Therefore, just as a security architecture should follow the principles of minimal attack surface and least privilege, the choice of security mechanisms should be based on the principles of simple, yet coherent design and least overlap.

Many security mechanisms or solutions offer a multitude of features that cover a wide range of needs. Choosing solutions that have feature overlaps could result in an unnecessary increase of complexity during the integration and operation of the system without any gains in the robustness of the overall system. In practice, integrating solutions without properly configuring features that are not needed can even introduce additional vulnerabilities or increasing the attack surface of the overall system (e.g. by leaving exposed services with their default, and usually vulnerable, configuration).

    1.  

3.2.2 IT-Systems Security

R-201

Existing protection mechanisms in the used application should be used.

Many applications that are used in a common IT operation today ship with a variety of very good quality IT security mechanisms. It is very important to know, understand, and ultimately use these provided functionalities. The addressed security functions have to be analysed, understood (especially with regards to the configuration possibilities) and used correctly.

Because the vendors of the various applications tend to implement these mechanisms by themselves, the existing protection mechanisms usually provide a good understanding of the application results as well as a good knowledge of potential weaknesses. Therefore, they can also provide a solid mechanism to protect the application against attacks which are tailored to use these weaknesses.

 

R-202

Usage of anti-malware software must be implemented throughout the organisation.

One of the most common and very important aspects of IT security is the protection against malware (e.g. viruses, spyware, adware, rootkits, ransomwares, trojan horses). Every day, hundreds of thousands new malware and potentially unwanted applications are registered[2].

The common propagation mechanism of malware is the Internet (e.g. malicious e-mails, visiting of web pages). However, systems which are operated offline can also be infected via alternative ways such as media storage devices. This means that every system should be protected by anti-virus programs, even if it is operating offline.

In order to speed up the investigation efforts of the anti-virus programs, some of the tasks are performed centrally (e.g. checking of the incoming e-mail or monitoring of the internet traffic), whereas others are computed locally (e.g. monitoring of the executable files or scripts, checking of the macros and content of the mounted external storage devices like a pen drives or external hard disks). The local monitoring should be performed continuously on the fly, but scans of the whole system should be periodically performed in regular intervals as well. Finally, the most important thing is to keep the anti-virus programs, especially their malware description database, constantly updated.

Even if the malware protection program (including the malware recognition database) is kept constantly up-to-date and the malware protection strategy includes almost all the requirements mentioned above, there are still additional risks that cannot be mitigated in this way. Therefore, it is still important to combine this approach with others, such as the requirements described in section 3.2.4.

 

R-203

Data access should be restricted to the minimum level needed.

One of the most important rules of IT security is the “need-to-know” principle. In other words, users (including a privileged one – i.e. an administrator or a root) should only have access to those features/programs and information, which are necessary for their everyday work. By using state-of-the-art approaches that implement role-based access control (RBAC) the implementation of this rule can be achieved without huge expenses. According to RBAC, the particular access rights are connected directly to corresponding roles. A set of roles can be combined in a group. A specific role/roles or group/groups can be assigned to a user and by doing so, the users would indirectly be allowed to execute specific actions in the system and access dedicated information as derived from their individual access rights.

A suitable access management allows the ongoing monitoring of the current concentration of access rights as well as the elaboration of strategies for its minimization. Regular checks are necessary. Especially business processes implicating a change of business roles (e.g. transfer to other organisational unit implies assignment of new access rights but also deletion of the rights, which are not needed any more) should be a major focus. Another important point which is commonly neglected is the revocation of the permissions for staff that leaves a company.

 

R-204

Roles and profiles must be assigned to all system users.

Access authorization should not be assigned to individual persons or groups directly. When large numbers of persons have to be administered, this approach inevitably requires substantive administrative effort, is highly complex, and therefore highly susceptible to errors. Almost all standard applications offer the possibility to define appropriate authorisation profiles and creating suitable roles. Every user (and every administrator) is assigned one or more permissible roles, which can be assumed during work. This not only permits simpler (and therefore more secure) authorisation management; it also enables more flexibility, as the same person can assume different roles depending on the particular tasks or activities currently performed.

 

R-205

Administrator privileges should be restricted to the minimum.

Many system administrators work under an administrative role which is subject to virtually no restrictions and enables extensive system privileges. The administrator could abuse this fact while also raising the risk of successful privilege escalation by unauthorised third parties. Therefore, if possible, different administrative functions should be defined. For example, depending on the administrative role, it is possible for one administrator to manage only the printers, another to create new users and a third to be responsible for backups. Ideally, there would even be a separate administrator to analyse logged data and monitor the other administrators' work.

It is an observed tendency that the concertation of the access rights especially by the members of those groups could lead to disastrous consequences. Centrify’s survey[3] of 1.000 IT decision makers in the U.S. and U.K. found out that 74% of breaches involved access to a privileged account. A functional and effective Privileged Access Management (PAM), as a part of Access management (AM) as a whole, is of great importance.

 

R-206

Application privileges should be restricted to the minimum.

Executable programs, as well as the users themselves, have certain access rights and system privileges assigned to them. In many cases, a program will simply inherit the permissions of the user who executes it. Sometimes these authorisations are not sufficient such as the case of server processes, which often have to be configured with extensive privileges. In such cases, programs sometimes possess permissions of dedicated privileged users (e.g. “root”) and can use all the accessible system resources. If such programs are used by an aggressor in a way in which they were not intended to be used, the aggressor will inherit all the permissions that go with the misused program. Thus, programs should also only be assigned the access rights required for them to work properly.

 

R-207

The standard (default) vendor configuration needs to be changed.

Most of the IT systems come with a pre-set manufacturer configuration. By doing so, the freshly installed system can be used in a smooth and convenient manner directly after its installation. Unfortunately, the convenience and security are two opposing concepts and IT security aspects do not always play the main role in the choice of the default values by the vendors. The out-of-the-box installations come usually with as few restrictions as possible in their default configuration. This means that weak and broadly known default passwords (also for the administrator), default users and relative unrestricted communication with the application (not sufficient secured interfaces and broadly open interfaces) are in place. These have to be adjusted in order to avoid possible misuse. A freshly installed system must not be released for production if the underlying configuration has not been customized and the system sufficiently secured.

Very often, the systems which are of higher importance for the business must be subject to additional hardening measures, such as:

  • Only the minimum number of administrative accounts is active
  • No default users are active
  • Default usernames and passwords have been changed
  • Only the absolutely necessary functionality is active
  • Only the absolutely necessary interfaces are enabled
  • Sufficient authentication and authorisation measures are implemented
  • No other systems are installed on the same node (separation)
  • The appropriate regular maintenance processes are in place
  • The provided update strategies have been implemented

 

R-208

Product manuals and documentation should be read in time.

An experienced administrator will often be in a position to boot up a system without reading the operating manuals in advance. However, this is often unreliable. For example, manufacturer warnings can be overlooked resulting in unexpected problems later on, such as incompatibilities, system crashes or undetected vulnerabilities. It would be prudent not to ignore the guidance provided by the manufacturer and, thus, create unnecessary risks.

 

R-209

Detailed documentation of the installation and the system itself must be created and regularly updated.

It is advisable to document all the operator actions performed prior to, during and after an installation, in writing. This will make it possible to recover more quickly from potential problems and to locate the possible causes. It is also important that the system documentation can be understood by third parties (e.g. by a "stand-in" administrator when the main administrators are away from office). This reduces the risk of failures in the event that the full-time administrator is suddenly no longer available. Moreover, if an attack is carried out, unauthorised changes to the system will be identified more quickly.

 

3.2.3 Networks

R-301

Networks should be protected by appropriate security mechanisms (firewall, NIDS, clustering, etc.)

No computer used for business purposes should be connected to the Internet without the protection of a suitable firewall. Even within relatively large internal networks, there are usually several subnets with different user groups and different security requirements. Therefore, it is often necessary to protect one's "own" subnet against adjacent networks to ward off threats, which may be qualitatively similar to threats from the Internet (e.g. isolation of the Human Resources department from the rest of the organisation). Therefore, appropriate protection mechanisms should be installed on those networks.

 

R-302

Implemented network security mechanisms must satisfy certain minimum requirements.

To protect the internal network against other, less trusted networks, an appropriate firewall type must be selected. The design of the firewall architecture, firewall installation and the internal intrusion detection systems should be done by specialists.

Generally, a multi-level firewall concept is recommended, under which additional filter elements (for example routers) are positioned in the upstream and downstream communication. If there is only a single computer or a complex firewall system is not feasible, it is recommended to install a personal firewall on the computer to be protected and, thereby providing at least basic protection.

The filter rules in firewalls tend to grow and become more complicated with time. Most of the times, the firewall administrators comply with requests from users all too lightly, thus watering down the rules. However, there should be no security exceptions regardless of their position in the company. It is therefore necessary to check at regular intervals, whether the existing filter rules are still consistent, whether they can be simplified and whether they are sufficiently restrictive. Moreover, checks should be carried out periodically as to whether the existing firewall design can still cope with communications protocols that have already been introduced or are expected to be used in the near future. Finally, new technologies can pose additional challenges to existing firewall concepts.

Even the security enabling systems like firewalls can fall victim to a successful cyber-attack. Defence strategies that are designed with multiple levels are necessary in order to be able to maintain a minimum amount of protection even when one firewall component has been compromised.

Apart from the firewalls, networks need to be monitored and the logs need to be securely stored and processed in a manner that ensures traceability of all network related incidents.

 

R-303

Data accessible by outsiders should be restricted to the minimum.

A lot of confidential information is provided to authorised users over open networks. This means that provided data can be accessed from outside the system. In this case, data protection depends solely on reliable authentication and authorisation mechanisms. However, if these mechanisms are configured/implemented incorrectly or they contain a vulnerability, information requiring protection can easily fall into unauthorized hands. It is therefore necessary to always check whether data that requires protection has to be made available and processed outside the organisation's own network individually.

 

R-304

Services and application features accessible by outsiders should be restricted to the minimum.

Every service or open communication port that is offered to the outside world increases the risk of a possible security loophole. Therefore, it is important to carefully check whether services need to be enabled, thereby possible exposing an attack vector. The associated security risk can vary depending on the relevant technology and implementation. With existing installations, regular checks should be carried out as to whether individual services or functions have not simply been enabled by mistake or out of convenience without an actual use case. The time gained by the reduction in administrative effort that results from such measures can then the be directed into the security administration of the remaining processes.

 

R-305

Particular caution should be exercised when handling web browsers; risky actions should be strictly prohibited.

Only active content, scripting languages and multimedia plug-ins that are essential for the work to be performed should be enabled in web browsers. In particular, risky scripting languages should be disabled, without exception.

 

R-306

Particular caution should be exercised regarding e-mail attachments.

The file attachments appended to incoming e-mails can contain damaging functionality if executed. No user should innocently open such attachments without checking them first. It is imperative to use a virus protection program. If in doubt, the recipient should check with the originator before opening an attachment. One particular problem is that certain e-mail programs open and execute attachments directly without asking the user for confirmation. Automatic opening of e-mail attachments can be technically prevented by selecting an e-mail program that does not have this functionality, by implementing appropriate configuration settings, or by installing add-on programs.

 

R-307

A stand-alone internet appliance used for surfing could be a low-cost solution for most security problems related to the use of the Internet.

One simple and cheap way of reducing the number of risks associated with surfing on the Internet is to set up a stand-alone appliance (such as a PC), which is not connected to the internal network. This can be used for internet research without having to give up functionality and convenience. Downloaded files can be checked for viruses on this dedicated system and then be passed on via data media or via other dedicated mechanisms into the internal network. This approach is only suitable for highly secured environments and cannot be adopted easily by the majority of organizations due to cost and convenience.

    1.  

3.2.4 The human factor

R-401

Security policy and requirements must be followed.

Security policies can only help if users follow them. Even the best security functions and programs are of no benefit if they are used infrequently or not at all. The consistent observance of all the necessary security requirements is a learning process for every individual in the underlying organisation and only works in the long-term once it becomes routine.

The entire staff should have a basic understanding of IT security, be able to follow the relevant lines of argument and assess the dangers. Even the most sophisticated security policy cannot cover every security aspect of the daily working life.

 

R-402

Order should dominate at the workplace and no personal or confidentail information should be freely accessible.

In the context of IT security orderliness is without doubt an excellent way of avoiding additional risks.

Confidential files should be securely locked in a cabinet or safe at the end of the day. Data storage devices such as external hard disks or USB sticks containing confidential material should never be left lying around. If necessary, they should be properly disposed of to prevent unauthorised persons from reconstructing the data that was stored on them.

Confidential printouts should be shredded and not thrown in the normal waste paper basket. Data media such as hard disks or CD-ROMs must be securely deleted or destroyed.

Of course, the implementation of this safeguard depends on data and files having been rated as personal or confidential in the context of an assessment of protection requirements and staff being familiar with these requirements.

 

R-403

Special precautions should be taken in the case of maintenance and repair work.

When computers or individual hard disks are repaired or thrown away, it is possible for unauthorised people to view or reconstruct confidential data (and normally even on defective data media). Service technicians should therefore never be left unsupervised while working on IT systems or private branch exchanges. When data media is to be taken off-site, all data must be wiped beforehand or the necessary confidentiality agreements should be signed.

Files which are deleted in the conventional way can subsequently be read either solely or partially using special tools. Important files must therefore be "securely deleted". Add-on programs are available for this purpose for all standard operating systems.

 

R-404

Staff has to participate in regular training.

Many mistakes arise because of ignorance or lack of awareness on the potential threats or hazards. This statement obviously applies to IT security as well. Thus, regular training is essential for administrators and IT security managers. When budgeting it is important not to be frugal with training, even if expensive options such as attending outside seminars are not possible. Purchasing high quality technical literature can quickly pay off.

However, training should not just cover technical topics. Often, the weakest link in the security chain are the employees that can be tricked to reveal confidential information or give access to privileged systems via social engineering.

Safeguards should therefore be taken at regular intervals to increase security awareness among all the staff concerned. This can be done in a variety of ways: internal lectures, training courses, circulated memos, posters, graphic examples, publication of security incidents etc.

It is also important to inform staff of the channels available for communicating with business partners: Who are the contacts? What competence level do they have? Which process must be followed for authorisation? Which information may be forwarded to external parties?

Lines of communication, too, need to be explained: What data may be exchanged via e-mail? What are the business partners’ correct phone numbers and URLs?

 

R-405

Only an honest self-assessment will help: sometimes it is necessary to call in the experts for advice.

The necessary technical knowledge on all aspects of IT security will not always be available within the organisation. qualification safeguards are often not sufficient, as the people concerned may not have the resources required for mastering all technical requirements. Here it is necessary to rethink and redefine responsibilities. It may be wise to call on external help or to outsource technical tasks to service providers. The overestimation of one's own capabilities can have adverse consequences.

 

R-406

Audits should be arranged for all existing security objectives.

Comprehension, acceptance and willingness on the part of the staff with regard to all the required security safeguards is always the uppermost aim. However, these requirements can be ignored for a number of reasons. Deliberate disregard is the exception rather than the rule, while mistakes and carelessness are the most common causes. Risk avoidance through suitable safeguards is in the interests of everyone. For this reason, it is necessary to consider how compliance can be monitored for every security objective. For example, monitoring may entail the use of technical tools or dedicated auditors, through analysis of logged data or spot checks by managers etc. Equally important is offering the possibility of self-regulation should be offered, for example by giving suitable checklists to staff. Optionally, such completed checklists can then be signed and passed on to the administration.

 

R-407

The consequences of security breaches should be described and published.

All those involved should be aware that (intentional or unintentional) disregard of security requirements will incur disciplinary safeguards. It should be clearly noted (for example, in the organisation's security policy) what these consequences will be.

 

R-408

Detected security breaches should have consequences.

If any security breaches are discovered the line manager needs to deal with the guilty party in an appropriate manner. Tough sanctions for mild breaches would be inappropriate, especially if it is the first such occasion. However, it is equally wrong not to act in case of more serious breaches or persistent offenders, since this could lead to a lack of obedience in the long run. Therefore, an appropriate response is required where necessary. The fact that breaches will incur disciplinary action must be communicated to everyone, as far as the particular business environment permits.

 

3.2.5 IT-Systems Maintenance

R-501

Security updates must be regularly installed

Given how fast new viruses can spread, implementing anti-virus software security updates must be a top priority. Updates of web browsers, e-mail programs and operating systems should likewise be carried out at regular intervals. Moreover, other application software and particular hardware components also have to be regularly maintained.

In larger organizations, the use of update roll-out tools that push out patches (e.g. MS SCCM) can be a valuable addition to ensuring correct maintenance. Apart from security updates, central configuration management tools can help in preventing and responding to vulnerabilities and internal incidents.

 

R-502

Detailed research on the security characteristics of the applications used should be carried out periodically.

It is vital to stay informed of newly identified vulnerabilities and tools when protecting IT systems. The latest recommendations on the Internet and technical articles can assist here. New program versions (e.g. of browsers) often eliminate known security-relevant vulnerabilities. However, this does not obviate the need to consider this matter on an individual basis, as new versions usually contain new functions and bugs that bring other risks.

Every system manager should regularly take time for appropriate searching/investigating as well as exchanging information with professional colleagues. A number of information services that are free of charge exist.

Moreover, the abundance of updates and security patches that are constantly being published requires a selection process. Usually not all are installed, especially as an immediate safeguard. Therefore, an advanced agreement should be put in place on the selection criteria to be applied when deciding which updates can or must be installed and with what time delay.

 

R-503

An action plan for installing necessary security updates should be created.

Even if the system manager does not install important security updates, this does not mean that the system automatically stands still or that a malicious hacker attack will take place immediately. This makes clear that the installation of updates requires considerable discipline and must be laid down as a process in advance. In the case of anti-virus software, the fastest possible installation of updates should become the routine.

 

R-504

Software changes should be tested.

In theory, every software change to productive systems should be exhaustively checked in advance in a test environment, thereby ensuring that all systems will still function as expected once the change is implemented. This applies to both architectural and implementation levels.

For instance, a virus protection program update can paralyse corporate networks if in-house software is incorrectly identified as a new virus and subsequently disabled.

Testing important security updates usually takes place under time pressure, as they need to be installed as soon as possible. Administrators must therefore carefully weigh the IT security requirements against the available resources and derive reasonable compromises.

    1.  

3.2.6 Security policies

R-601

A security policy should be properly documented in the corresponding security concept.

The document(s) that bind together an organization’s system operations and human activities in terms of information security is called security policy. A security policy contains the roles and responsibilities as well as the rules and procedures for each individual that is using the organizations assets or resources. While the actual document structure and scope is heavily dependent on the organization’s size and needs, standards such as ISO 27001 [ISO27001] and the security policy requirements as dictated in NIST Special Publication 800-35 [NIST800-35] can be valuable tools for the composition of a complete and, in case it is needed, compliant security policy. The security policy should be approved and supported by the security officer and the organization management and should be known and clear to all of the organization staff.

 

R-602

A sensible password policy should be adopted.

The password policy is one of the standard policies that should be implemented and enforced in an organization. Due to the increase of processing power that can be used for password cracking, strong passwords are mandatory for the robustness of the access control mechanisms of the organization’s hosts and services.

One trade-off that should be considered is the possibility that a very strict password policy could potentially result in passwords that are not easy to be remembered by the users, who in turn write them down and leave them in easily accessible places. The same holds true for high frequency password reset policies. Sometimes it is preferable to make sure that the policy allows the use of high entropy passwords containing easy to use phrases even if those passwords stay valid for longer periods of time [HIC2016]

Apart from passwords, authentication can be enhanced by a second factor such as a hardware token or OTPs sent to mobile devices. Such 2-factor authentication is becoming the default policy for systems that process personal or confidential data.

 

R-603

Workstations should be secured in the absence of their owner by a password-protected screensaver.

Physical access to a user’s host machine is one of the attack vectors that cannot be easily covered by the usual cyber-security mechanisms. The impact of such a breach is proportional to the access level of the user whose station is compromised. Therefore, for the hosts that are available to users with a higher access level, the default policy should be a screen lock with a short time threshold and mandatory password protection. This ensures the minimum amount of time that a host remains unprotected remains as low as possible.

 

R-604

Sensitive data and systems must be protected according to their asset value.

The systems and services that require protection within an organization (i.e. the assets) have a different “value” assigned to them depending on the type of data or operations that they host or process. Since the implementation of a security policy does not come without cost, the amount of protection, in the form of deployed security mechanisms and implemented security operations that each asset warrants, should be decided based on the asset’s perceived value. The result can be that, for example, accessing specific systems requires 2-factor authentication or that changes to specific data are tracked up to 1 month.

 

R-605

Responsibilities must be clearly defined and assigned.

One important part of a well-designed security policy is the clear definition of actors, roles and responsibilities within the system’s operational environment. While the redundancy of actors is a good property for the continuous operation of the system, the redundancy in responsibilities often leads to a lower accountability and to longer reaction times during a security incident.

As a rule, each role should have a small number of clearly defined responsibilities without any overlaps between roles. In addition, the number of actors for each role should be adequate to ensure the continuous operation of the system. Lastly, the number of roles per actor should be equal to the number of non-overlapping responsibilities for each actor.

 

R-606

IT security should be audited regularly.

The correct implementation of the security policies is of equal importance as its correct design. Security audits conducted by internal or external experts are one of the main controls that ensure the continuous correct implementation of said policies. Part of the design of security policies should be the documentation of the controls that are to be used during audits. While external audits are sometimes the only way of proving the correct operation of the system to an external regulator, depending on the access level the organization is willing to give to external entities during an audit, some parts of the system can only be audited by internal yet autonomous security experts. A well-documented auditing procedure is therefore vital for proving the system’s trustworthiness to an external regulator. This holds true especially in the context of systems that handle and share personal or confidential data.

 

[1]  In some cases, there could be a need to separate the authenticity from integrity, but as a rule, it is a part of the integrity.

[3]  https://www.centrify.com/resources/centrify-privileged-access-management-in-the-modern-threatscape-2019/

secure-data-scds
Bildnachweis:
Support Centre for Data Sharing