Personnel Security

Personnel security are the controls that enable people to play their foundational role in protecting information and information systems of the organization. All people have responsibilities to properly use the protective controls. Some people are additionally trusted to support the correct design or operation of security controls. Thus, personnel security is the foundation upon which all other controls operate. This section discusses key elements of personnel security and the associated roles.

Screening

Applicants for job openings are screened to prioritize the best qualified candidate to hire. The security screening is intended to confirm the candidate’s trustworthiness and can vary depending on the level of trust associated with the position. Screening can involve credit checks and inquiries into police records. Formal organization criteria should be applied by the person in authority to accept or reject a candidate.

Establish Duty to Protect

On the first day, every new employee typically signs an employment contract. One component establishes their duty to protect the organization’s proprietary information and information systems. There may be an additional information protection agreement or a system use agreement signed during an employee’s career, such as when government classified information is involved.

Security Briefings, Training and Awareness

The security leader is challenged with the fact that people are the first line of defense and are also as a group the weakest element of defense. Illustrative examples include allowing tailgaters through physical access controls, leaving a list of userids and passwords beside their workstation, and clicking on links within (what should be) suspicious SPAM email.

Your organization’s first day employee training needs a component on security practices relevant for everyone. You will also want specialized briefings for other roles such as managers and system administrators. The objective on the first day is that organization executive’s security expectations are understood and internalized by every new employee. Avoid death by PowerPoint, which will win no converts.

Additional training is appropriate when specific security skills must be learned, such as secure application development practices. It is unfortunately common for organization to invest in slick training modules and an array of current topics followed by a quiz to confirm skills. You will want to analyze the risk reduction benefit before proposing the investment in both development time and employees training time.

Promote Awareness

Employees receive education, training and awareness materials with the expectation that they will be equipped to play their very important role for information security. Do not underestimate the importance or difficulty of influencing user behavior. It is best to prioritize the few user behaviors that are of greatest importance, then reinforce them at reasonable intervals through the chain of control. For example, if wearing the organization badge is a key control, then the organization executive must model behavior by always being seen wearing the badge where it is clearly visible.

The organization executive must “walk the talk” on following security practices. Executive staff will naturally copy the executive’s behavior. Whenever some security incident or new practice is shared with employees, the organization executive must be the primary speaker, with you sufficiently visible on explaining details to reinforce your role.

Very selective use of security reminders can help users so long as they are relevant and helpful. By contrast, use of generic posters, such as “remember security” with a comical picture, is more likely to decrease your credibility then have any beneficial impact.

Finally, there will be instances when individuals fail to follow security practices. This results in an adverse impact to the organization. Your investigations organization presents findings to the disciplinary function who determines appropriate disciplinary action for the individual. It is valuable to publicize a summary of the investigation (non-attributed) including the disciplinary action as a practical reminder of the importance of personnel security and the consequences of failures.

Copyright © 2019 Christopher T. Carlson

Excerpt from How to Manage Cybersecurity Risk – A Security Leader’s Roadmap with Open FAIR

Return to Defense in Depth

Design Defense in Depth

Defense in depth is the application of multiple layers of controls are to defend against threats. Many security controls are applicable to a variety of assets and numerous threats. In some cases, the controls applied to one layer of defense may be redundant (e.g. belt and suspenders). In other cases, the controls may have complementary characteristics.

The following figure illustrates layers of defense, protecting the assets identified at the bottom.

Layers of Controls

Layers will be discussed in the following posts:

Copyright © 2019 Christopher T. Carlson

Excerpt from How to Manage Cybersecurity Risk – A Security Leader’s Roadmap with Open FAIR

 

Vocabulary – Vulnerability

Introduction

Dictionary defines: vulnerability – open to attack, harm, or damage

CIS RAM defines: vulnerability – A weakness that could permit a threat to compromise the security of information assets.

Not simple.

ISO/IEC 27000 defines: vulnerability – weakness of an asset or control that can be exploited by one or more threats

Not simple

PCI DSS defines: vulnerability – Flaw or weakness which, if exploited, may result in an intentional or unintentional compromise of a system.

Not simple

CNSS defines: vulnerability – Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited.

Not simple and relies on specialized terms

O-TTPS defines: Vulnerability – A weakness in the design, implementation, or operation of an asset, artifact, system, or network that can be exploited.

Not simple and relies on specialized terms

CVE defines a vulnerability – A weakness in the computational logic (e.g., code) found in software and hardware components that, when exploited, results in a negative impact to confidentiality, integrity, or availability.

Not simple and relies on specialized terms

EAS defines: vulnerability – A weakness in system security procedures, design, implementation, internal controls, etc. that could be accidentally triggered or intentionally exploited and could result in a violation of the system’s security policy

Not simple and relies on specialized terms

ISACA defines: vulnerability – A weakness in the design, implementation, operation or internal control of a process that could expose the system to adverse threats from threat events

Not simple and relies on specialized terms

NIST 800-53 defines: vulnerability – Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.

Not simple and relies on specialized terms

OWASP describes: vulnerability – a hole or a weakness in the application, which can be a design flaw or an implementation bug, that allows an attacker to cause harm to the stakeholders of an application.

Not simple and relies on specialized terms

STIX defines: vulnerability – a mistake in software that can be directly used by a hacker to gain access to a system or network

Not simple and relies on specialized terms

FAIR defines: vulnerability – The probability that a threat event will become a loss event (which occurs when a threat agent acts against an asset)

Describes how to measure vulnerability rather than defining what it is.

SDL defines: threat – an attacker’s objective

This definition is related to definitions of vulnerability rather than threat, assuming the reader understand that “objective” refers to the vulnerability the attacker seeks to exploit.

Vocabulary – Threat

Introduction

Dictionary defines: threat – someone or something that could cause trouble, harm, etc.

  • Note that the definition has a subject and an object

FAIR defines: threat – Anything that is capable of acting in a manner resulting in harm to an asset and/or organization

  • Slightly more specific than the dictionary

ISACA defines: threat – Anything (e.g., object, substance, human) that is capable of acting against an asset in a manner that can result in harm.

  • Slightly more specific than FAIR

ESA defines: threat – the potential for a “threat source” to exploit (intentionally) or trigger (accidental) a specific vulnerability.

  • Complicated by use of threat source and specialized term vulnerability. Lacks an object.

O-TTPS defines: Threat – The intention and capability of an adversary to undertake actions that would be detrimental through disruption of processes or subversion of knowledge.

  • Complicated by thoroughly describing the nature of a threat.

CIS defines: threat – A potential or foreseeable event that could compromise the security of information assets.

  • Complicated by suggestion that threats should be foreseeable and extraneous description of harm

CNSS defines: threat – Any circumstance or event with the potential to adversely impact an IS through unauthorized access, destruction, disclosure, modification of data, and/or denial of service.

  • Complicated definition.

ISO/IEC 27000 defines: threat – potential cause of an unwanted incident, which can result in harm to a system or organization

  • Complicated by ambiguous word incident.

NIST 800-53 defines: threat – Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service.

  • Overly specific for a definition.

OWASP contains a Category: threat – A threat that plague a product. While known threats are identified based on signatures, files copied onto the hard drive upon installation, registry keys, protocol analysis and others.

  • Circular and uses specialized terms and concepts.

PCI DSS defines: threat – Condition or activity that has the potential to cause information or information processing resources to be intentionally or accidentally lost, modified, exposed, made inaccessible, or otherwise affected to the detriment of the organization

  • Overly specific for a definition

STIX defines: threat actors – actual individuals, groups, or organizations believed to be operating with malicious intent.

  • Identifies a who but no what.

SDL defines: threat – an attacker’s objective

  • Identifies a what but no who.

Vocabulary – Risk

Introduction

Dictionary defines: risk – possibility of loss

FAIR defines: risk – the probable frequency and probable magnitude of future loss.

More complete than the dictionary

COBIT and ISACA defines: risk – the combination of the probability of an event and its consequence

The term “event” is ambiguous introducing complexity

O-TTPS defines: Risk – An event or condition that has a potentially negative impact and the possibility that such an event will occur and adversely affect an entity’s assets and artifacts, activities, and operations.

Complete but verbose.

OWASP defines: risk – Risk is the possibility of a negative or undesirable occurrence. There are two independent parts of risk: Impact and Likelihood.

Relies on context for specialized terms.

CIS defines: risk – an estimation of the likelihood that a threat will create an undesirable impact.

Relies on context for specialized terms.

CNSS defines: risk – possibility that a particular threat will adversely impact an IS by exploiting a particular vulnerability

Relies on context for specialized terms

NIST CSF and 800-53 defines: risk – a measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence.

Not simple. Relies on context for specialized terms

PCI DSS defines: risk assessment – Process that identifies valuable system resources and threats; quantifies loss exposures (that is, loss potential) based on estimated frequencies and costs of occurrence; and (optionally) recommends how to allocate resources to countermeasures so as to minimize total exposure.

Not simple. Provides a description rather than a definition.

ESA defines: IT-related risk – the net mission/business impact (probability of occurrence combined with impact) from a particular thereat source exploiting, or triggering, a particular information technology vulnerability.

Not simple. Relies on context for specialized terms

ISO 27000 defines: risk – effect of uncertainty on objectives

Unclear by choice of defining terms.