NIS Directive: are you ready?

UNADJUSTEDNONRAW_thumb_3de4

Governments across Europe recognised that with increased interconnectiveness a cyber incident can affect multiple entities spanning across a number of countries. Moreover, impact and frequency of cyber attacks is at all-time high with recent examples including:

  • 2017 WannaCry ransomware attack
  • 2016 attacks on US water utilities
  • 2015 attack on Ukraine’s electricity network

In order to manage cyber risk, the European Union introduced the Network and Information Systems (NIS) Directive which requires all Member States to protect their critical national infrastructure by implementing cyber security legislation.

Each Member State is required to set their own rules on financial penalties and must take the necessary measures to ensure that they are implemented. For example, in the UK fines, can be up to £17 million.

And yes, in case you are wondering, the UK government has confirmed that the Directive will apply irrespective of Brexit (the NIS Regulations come into effect before the UK leaves the EU).

Who does the NIS Directive apply to?

The law applies to:

  • Operators of Essential Services that are established in the EU
  • Digital Service Providers that offer services to persons within the EU

The sectors affected by the NIS Directive are:

  • Water
  • Health (hospitals, private clinics)
  • Energy (gas, oil, electricity)
  • Transport (rail, road, maritime, air)
  • Digital infrastructure and service providers (e.g. DNS service providers)
  • Financial Services (only in certain Member States e.g. Germany)

NIS Directive objectives

In the UK the NIS Regulations will be implemented in the form of outcome-focused principles rather than prescriptive rules.

National Cyber Security Centre (NCSC) is the UK single point of contact for the legislation. They published top level objectives with underlying security principles.

Objective A – Managing security risk

  • A1. Governance
  • A2. Risk management
  • A3. Asset management
  • A4. Supply chain

Objective B – Protecting against cyber attack

  • B1. Service protection policies and processes
  • B2. Identity and access control
  • B3. Data security
  • B4. System security
  • B5. Resilient networks and systems
  • B6. Staff awareness

Objective C – Detecting cyber security events

  • C1. Security monitoring
  • C2. Proactive security event discovery

Objective D – Minimising the impact of cyber security incidents

  • D1. Response and recovery planning
  • D2. Lessons learned

Table view of principles and related guidance is also available on the NCSC website.

Cyber Assessment Framework

The implementation of the NIS Directive can only be successful if Competent Authorities  can adequately assess the cyber security of organisations is scope. To assist with this, NCSC developed the Cyber Assessment Framework (CAF).

The Framework is based on the 14 outcomes-based principles of the NIS Regulations outlined above. Adherence to each principle is determined based on how well associated outcomes are met. See below for an example:

NIS

Each outcome is assessed based upon Indicators of Good Practice (IGPs), which are statements that can either be true or false for a particular organisation.

Whats’s next?

If your organisation is in the scope of the NIS Directive, it is useful to conduct an initial self-assessment using the CAF described above as an starting point of reference. Remember, formal self-assessment will be required by your Competent Authority, so it is better not to delay this crucial step.

Establishing an early dialogue with the Competent Authority is essential as this will not only help you establish the scope of the assessment (critical assets), but also allow you to receive additional guidance from them.

Initial self-assessment will most probably highlight some gaps. It is important to outline a plan to address these gaps and share it with your Competent Authority. Make sure you keep incident response in mind at all times. The process has to be well-defined to allow you report NIS-specific incidents to your Competent Authority within 72 hours.

Remediate the findings in the agreed time frames and monitor on-going compliance and potential changes in requirements, maintaining the dialogue with the Competent Authority.

Advertisements

Using SABSA for application security

Aligning OWASP Application Security Verification Standard and SABSA Architecture framework.

OWASP Application Security Verification Standard (Standard) is used at one of my clients to help develop and maintain secure applications. It has been used it as blueprint create a secure coding checklist specific to the organisation and applications used.

Below is an excerpt from the Standard related to the authentication verification requirements:

OWASP

The Standard provides guidance on specific security requirements corresponding to the Physical layer of the SABSA architecture.

SABSA views

As there’s no clear link to the business requirements, let’s perform alignment between two frameworks.

The first step is to gain an understanding of Contextual and Conceptual architectures.

From analysing the company’s corporate strategy I was able to derive multiple business attributes relevant to the shareholders:

Business attributes

After a workshop with the CIO and IT managers in various business units, I’ve defined the following IT attributes supporting the main business attributes and the relationships between them:

Business and iT attributes

How does the security function support the wider IT objectives and corresponding attributes? After a number of workshops and analysis of the security strategy document I’ve created a number of security attributes. Below is an example correlating to the business and IT attributes in scope:

security attributes

The next step is to develop the security attribute mapping to the requirements of an in-house application security policy, based on the OWASP Application Security Verification Standard:

Requirement Requirement Description
Authenticated
A1 Application must use established corporate directory services for authentication i.e. LDAP.
A2 Authentication must be performed over a secure connection like SSL/TLS to avoid data sniffing.
A3 Authentication mechanism must not store sensitive credentials on the client.
A4 Authentication credentials must not be submitted using URL parameters to avoid sniffing.
A5 Authentication failure response must never indicate which part of the authentication data was incorrect to prevent username enumeration.
A6 Password entry fields must enforce a combination of upper-case, lower-case, special-chars, numbers and a minimum length for secure password.
A7 All authentication controls must be enforced on the server side because it’s easy to tamper with data on the client side.
A8 Authentication credentials must be salted and stored using industry defined and proven hashing techniques.
A9 Forgot password and other recovery paths must send a link including a time-limited activation instead of the password itself.
A10 There must be no secret question and answer mechanism for resetting the password to thwart social engineering attacks.
A11 Forget password functionality must not disable the login for valid users to ensure valid users don’t get locket out.
A12 Authentication mechanism must define the account lockout policy in case of 3 to 5 wrong login attempts to avoid brute-force attacks.
Authorised
B1 Access Control process must be defined, agreed upon, and effectively implemented. The process must cover user authorization management, roles and responsibilities, and access revocation and expiry.
B2 The authorization business roles must be defined and documented.
B3 Authorization controls must be designed using the Principle of Least Privilege i.e. a user should not be granted excess privileges which is not required to perform his job.
B4 Business roles must never have authorization to perform application administration functions.
B5 An application must utilize a central component for authorization.
B6 Only trusted system objects must be used for making authorization decisions.
B7 Authorization check must be performed at every entry point of an application.
B8 Authorization controls must fail securely; all access must be denied if the application cannot access its security configuration information.
Managed
C1 The application must use the session management mechanism provided by the framework or server instead of a custom solution. Session management provided by the framework or server is thoroughly tested for security and hence safe to use.
C2 Session creation and management must be done on a trusted system and never on the client side.
C3 A new session must be established upon log-in and re-authentication to prevent session-fixation attacks.
C4 User must be forced to re-authenticate when attempting to access a function that requires elevated privileges.
C5 An idle session timeout and an absolute session timeout regardless of activity must be set.
C6 The logout function must explicitly terminate the user session and destroy all session related data.
C7 Session ids must have high entropy to avoid session id guessing attacks.
C8 The Session ID is sensitive; it must be protected and never displayed except in cookie headers.
C9 Session ID cookies must be marked as HttpOnly to avoid an XSS flaw from gaining access to it.
C10 User provided session ids must never be accepted.
C11 Concurrent session for the same user must not be allowed.
Validated
D1 All user-input coming from drop-down, text fields, value lists, and other UI components must be validated. By default the user input should be considered malicious.
D2 Special characters in input like (but not limited to) <, >, &, ’” if used in the output must be html escaped to make them context safe.
D3 Input validation and encoding must be performed on the server side.
D4 Queries passed to SQL databases must be parameterized or stored procedures should be used to prevent SQL injection attacks.
D5 All input validation failures must be logged to detect attack if any.
D6 Input validation failure message should not display any system or configuration information to the user. It may assist the attacker in profiling the system.
D7 Input validation failures must result in input rejection.
D8 File upload functions must be implemented securely. Uploaded file should be checked for virus and other malicious data
Controlled
E1 Error messages must not display any technical information about the application or the underlying infrastructure to thwart any attempt to profile the system.
E2 Application design must perform proper exception handling and must not solely rely on the underlying framework or infrastructure for handling errors.
E3 System resources that are no longer needed upon occurrence of an exception must be explicitly released.
E4 Application design must deny access by default.
Logged
F1 Logging controls must be implemented on a trusted system.
F2 Access to logs must be strictly controlled.
F3 Sensitive information must not be stored in system logs.
F4 Successful and unsuccessful login attempts must be logged.
F5 Attempts to access unauthorized sensitive transactions must be logged.
F6 Sensitive transactions and administrative actions must be identified and their usage logged.
F7 Unexpected application exceptions must be logged.
F8 Centralized monitoring of logs must be setup for critical applications.
F9 A log retention, access, and review process must be defined and effectively implemented.
Protected
G1 All sensitive data consumed and produced by an application must be classified and there should be a clear policy for access control to these data.
G2 The retention period must be obtained or determined for any data stored by an application.
G3 All sensitive information must be transmitted using the latest version of SSL/TLS.
G4 Only industry accepted encryption/hashing algorithms must be used. Outdated and weak hashing algorithm like MD5 should never be used.
G5 Data at rest must be protected by means of access control, and where required, by encryption
G6 Sensitive information must not be transmitted in GET query string or in URL parameter.
G7 User credentials must never be hard-coded or stored in config/plaintext files.
G8 An application must not reveal technical information about system components or underlying infrastructure.
G9 Unnecessary application code, documentation and components must be removed before deployment to production environment.
G10 Cookies sent over HTTPS must be marked as secure.
G11 Extranet applications must protect against Clickjacking attack by setting the iframe as same-origin in the cookie.
G12 Client side caching should be disabled for sensitive information using appropriate header or meta-tag like no-cache, Cache-Control, no-store.
G13 Temporary data or files must be invalidated after session termination.

Further aligning the application security policy to the SABSA framework, let’s invent the link between the SABSA layers, developing Logical, Physical and Component architectures:

Components

Note that the list of security requirements and control objectives is not exhaustive and presented for illustrative purposes only.

The Standard defines three security verification levels, with each level increasing in depth. Each ASVS level contains a list of security requirements. Each of these requirements can also be mapped to security-specific features and capabilities that must be built into software by developers.

Let’s map risk level for every security attribute and corresponding components to the Standard verification levels:

levels

The combined framework can now be used for high-level risk reporting:

dashboard

The OWASP framework is designed as a set of requirements to measure point-in-time compliance with the Standard. I propose widening the scope of the framework to include activities I performed above as part of the following lifecycle:

Cycle

Controls and control objectives are clearly defined in the Standard in order to address the risks, yet the focus on enablers to exploit potential opportunities is lacking. Below is an example of how a balanced approach might look like for the attribute Authenticated.

Attribute Enablement Objectives Control Objectives
Authenticated 1. Ensure that all essential enterprise information uses centralized authentication and access control mechanisms.

2. Encourage information creators and users to leverage centralized content repositories for all information essential to performing their day-to-day activities.

3. Where possible, use automatic assignment of information and data ownership and permissions to ensure information elements are accessed by only those individuals who have a legitimate business need.

4. Where possible, do not require users to explicitly manage individual access control permissions and authorizations.

Ensure that a verified application satisfies the following high level requirements:

1. Verifies the digital identity of the sender of a communication.

2. Ensures that only those authorised are able to authenticate and credentials are transported in a secure manner.

 

There is also a lack of metrics and performance targets in the OWASP Standard. To address this, I’ve developed a set of metrics and measurement approaches for security attributes with corresponding primary and secondary risk indicators. Below is an example for the attribute Authenticated.

Attribute Metric Measurement Approach Category Primary KRI Secondary KRI
Authenticated % of information elements stored in repositories, locations or on devices requiring authentication of some kind before the information can be accessed Audit of information repositories and storage locations.

 

Completeness 80% 90%
Authenticated % of applications using established corporate directory services for authentication Audit of web applications Completeness 80% 90%
Authenticated % of applications performing authentication over SSL/TLS Audit of web applications Completeness 80% 90%
Authenticated % of applications storing authentication credentials on the client. Audit of web applications Completeness 80% 90%
Authenticated % of applications enforcing password requirements Audit of web applications Completeness 80% 90%

How do you demonstrate benefits of the combined framework to the stakeholders?

The following stakeholders have been chosen to demonstrate features, advantages and benefits of the combined OWASP-SABSA framework as they are directly impacted by this change:

  • Chief Executive Officer (CEO) and the Board of Directors
  • Chief Risk Officer (CRO)
  • Chief Information Officer (CIO)
  • Chief Information Security Officer (CISO)

The table below provides a summary of benefits of the aligned framework.

Feature Advantage Benefit
CEO and Board CRO CIO CISO
Business-driven Value-assured Protects corporate reputation and Enables flexible fit with industry regulations Enables secure adoption of digital business model Facilitates alignment of application security efforts with business goals
Transparent Two-way traceability Ensures return on investment Enables effective compliance measurement approach Encourages integrated people – process – technology solutions Provides traceability of implementation of business-aligned security requirements
Auditable Demonstrates compliance to relevant authorities Demonstrates compliance to regulators and external auditors Ensures that compliance risk is effectively managed Facilitates effective internal information systems audits Supports application security and risk review processes

References:


How to conduct a cyber security assessment

NIST SCF

I remember conducting a detailed security assessment using the CSET (Cybersecurity Evaluation Tool) developed by the US Department of Homeland Security for UK and US gas and electricity generation and distribution networks. The question set contained around 1200 weighted and prioritised questions and resulted in a very detailed report.

Was it useful?

The main learning was that tracking every grain of sand is no longer effective after a certain threshold.

The value add, however, came from going deeper into specific controls and almost treating it as an audit where a certain category is graded lower if none or insufficient evidence was provided.  Sometimes this is the only way to provide an insight into how security is being managed across the estate.

Why?

What’s apparent in some companies – especially in financial services – is that they conduct experiments often using impressive technology. But have they made it into a standard and consistently rolled it out across the organisation? The answer is often ‘no’. Especially if the company is geographically distributed.

I’ve done a lot of assessments and benchmarking exercises against NIST CSF, ISO 27001, ISF IRAM2 and other standards since that CSET engagement and developed a set of questions that cover the areas of the NIST Cybersecurity Framework.

I felt the need to streamline the process and developed a tool to represent the scores nicely and help benchmark against the industry. I usually propose a tailor-made questionnaire that would include 50-100 suitable questions from the bank. From my experience in these assessments, the answers are not binary. Yes, a capability might be present but the real questions are:

  • How is it implemented?
  • How consistently it is being rolled out?
  • Can you actually show me the evidence?

So it’s very much about seeking the facts.

As I’ve mentioned, the process might not be the most pleasant for the parties involved but it is the one that delivers the most value for the leadership.

What about maturity?

I usually map the scores to the CMMI (Capability Maturity Model Integration) levels of:

  • Initial
  • Managed
  • Defined
  • Quantitatively managed and
  • Optimised

But I also consider NIST Cybersecurity framework implementation tiers that are not strictly considered as maturity levels, rather the higher tiers point to a more complete implementation of CSF standards. They go through Tiers 1-4 from Partial through to Risk Informed, Repeatable and finally Adaptive.

The key here is not just the ultimate score but the relation of the score to the coverage across the estate.


Building a security culture

Building on the connection between breaking security policies and cheating, let’s look at a study[1] that asked participants to solve 20 simple maths problems and promised 50 cents for each correct answer.

The participants were allowed to check their own answers and then shred the answer sheet, leaving no evidence of any potential cheating. The results demonstrated that participants reported solving, on average, five more problems than under conditions where cheating was not possible (i.e. controlled conditions).

The researchers then introduced David – a student who was tasked to raise his hand shortly after the experiment begun and proclaim that he had solved all the problems. Other participants were obviously shocked by such a statement. It was clearly impossible to solve all the problems in only a few minutes. The experimenter, however, didn’t question his integrity and suggested that David should shred the answer sheet and take all the money from the envelope.

Interestingly, other participants’ behaviour adapted as a result. They reported solving on average eight more problems than under controlled conditions.

Much like the broken windows theory mentioned in my previous blog, this demonstrates that unethical behaviour is contagious, as are acts of non-compliance. If employees in a company witness other people breaking security policies and not being punished, they are tempted to do the same. It becomes socially acceptable and normal. This is the root cause of poor security culture.

The good news is that the opposite holds true as well. That’s why security culture has to have strong senior management support. Leading by example is the key to changing the perception of security in the company: if employees see that the leadership team takes security seriously, they will follow.

So, security professionals should focus on how security is perceived. This point is outlined in three basic steps in the book The Social Animal, by David Brooks:[2]

  1. People perceive a situation.
  2. People estimate if the action is in their long-term interest.
  3. People use willpower to take action.

P-A-A

He claims that, historically, people were mostly focused on the last two steps of this process. In the previous blog I argued that relying solely on willpower has a limited effect. Willpower can be exercised like a muscle, but it is also prone to atrophy.

In regard to the second step of the decision-making process, if people were reminded of the potential negative consequences they would be likely not to take the action. Brooks then refers to ineffective HIV/AIDS awareness campaigns, which focused only on the negative consequences and ultimately failed to change people’s behaviour.

He also suggests that most diets fail because willpower and reason are not strong enough to confront impulsive desires: “You can tell people not to eat the French fry. You can give them pamphlets about the risks of obesity … In their nonhungry state, most people will vow not to eat it. But when their hungry self rises, their well-intentioned self fades, and they eat the French fry”.

This doesn’t only apply to dieting: when people want to get their job done and security gets in the way, they will circumvent it, regardless of the degree of risk they might expose the company to.

That is the reason for perception being the cornerstone of the decision-making process. Employees have to be taught to see security violations in a particular way that minimises the temptation to break policies.

In ‘Strangers to Ourselves’, Timothy Wilson claims, “One of the most enduring lessons of social psychology is that behaviour change often precedes changes in attitudes and feelings”.[3]

Security professionals should understand that there is no single event that alters users’ behaviour – changing security culture requires regular reinforcement, creating and sustaining habits.

Charles Duhigg, in his book The Power of Habit,[4] tells a story about Paul O’Neill, a CEO of the Aluminum Company of America (Alcoa) who was determined to make his enterprise the safest in the country. At first, people were confused that the newly appointed executive was not talking about profit margins or other finance-related metrics. They didn’t see the link between his ‘zero-injuries’ goal and the company’s performance. Despite that, Alcoa’s profits reached a historical high within a year of his announcement. When O’Neill retired, the company’s annual income was five times greater than it had been before his arrival. Moreover, it became one of the safest companies in the world.

Duhigg explains this phenomenon by highlighting the importance of the “keystone habit”. Alcoa’s CEO identified safety as such a habit and focused solely on it.

O’Neill had a challenging goal to transform the company, but he couldn’t just tell people to change their behaviour. He said, “that’s not how the brain works. So I decided I was going to start by focusing on one thing. If I could start disrupting the habits around one thing, it would spread throughout the entire company.”

He recalled an incident when one of his workers died trying to fix a machine despite the safety procedures and warning signs. The CEO called an emergency meeting to understand what had caused this tragic event.

He took personal responsibility for the worker’s death, identifying numerous shortcomings in safety education. For example, the training programme didn’t highlight the fact that employees wouldn’t be blamed for machinery failure or the fact that they shouldn’t commence repair work before finding a manager.

As a result, the policies were updated and the employees were encouraged to suggest safety improvements. Workers, however, went a step further and started suggesting business improvements as well. Changing their behaviour around safety led to some innovative solutions, enhanced communication and increased profits for the company.

Security professionals should understand the importance of group dynamics and influences to build an effective security culture.

They should also remember that just as ‘broken windows’ encourage policy violations, changing one security habit can encourage better behaviour across the board.

References:

[1] Francesca Gino, Shahar Ayal and Dan Ariely, “Contagion and Differentiation in Unethical Behavior: The Effect of One Bad Apple on the Barrel”, Psychological Science, 20(3), 2009, 393–398.

[2] David Brooks, The Social Animal: The Hidden Sources of Love, Character, and Achievement, Random House, 2011.

[3] Timothy Wilson, Strangers to Ourselves, Harvard University Press, 2004, 212.

[4] Charles Duhigg, The Power of Habit: Why We Do What We Do and How to Change, Random House, 2013.

To find out more about building a security culture, read Leron’s book, The Psychology of Information Security. Twitter: @le_rond


Security and Usability

Many employees find information security secondary to their normal day-to-day work, often leaving their organisation vulnerable to cyber attacks, particularly if they are stressed or tired. Leron Zinatullin, the author of The Psychology of Information Security, looks at the opportunities available to prevent such cognitive depletion.

2141071329_9097e63c06_o

When users perform tasks that comply with their own mental models (i.e. the way that they view the world and how they expect it to work), the activities present less of a cognitive challenge than those that work against these models.

If people can apply their previous knowledge and experience to a problem, less energy is required to solve it in a secure manner and they are less mentally depleted by the end of the day.

For example, a piece of research on disk sanitisation highlighted the importance of secure file removal from the hard disk.[1] It is not clear to users that emptying the ‘Recycle Bin’ is insufficient and that files can easily be recovered. However, there are software products available that exploit users’ mental models. They employ a ‘shredding’ analogy to indicate that files are being removed securely, which echoes an activity they would perform at work. Such an interface design might help lighten the burden on users.

Security professionals should pay attention to the usability of security mechanisms, aligning them with users’ existing mental models.

In The Laws of Simplicity,[2] John Maeda supports the importance of making design more user-friendly by relating it to an existing experience. He refers to an example of the desktop metaphor introduced by Xerox researchers in the 1980s. People were able to relate to the graphical computer interface as opposed to the command line. They could manipulate objects similarly to the way they did with a physical desk: storing and categorising files in folders, as well as moving or renaming them, or deleting them by placing them in the recycle bin.

Using mental models

Building on existing mental models makes it easier for people to adopt new technologies and ways of working. However, such mappings must take cultural background into consideration. The metaphor might not work if it is not part of the existing mental model. For instance, Apple Macintosh’s original trash icon was impossible to recognise in Japan, where users were not accustomed to metallic bins of this kind.

Good interface design not only lightens the burden on users but can also complement security. Traditionally, it has been assumed that security and usability always contradict each other – that security makes things more complicated, while usability aims to improve the user experience. In reality, they can support each other by defining constructive and destructive activities. Effective design should make constructive activities simple to perform while hindering destructive ones.

This can be achieved by incorporating security activities into the natural workflow of productive tasks, which requires the involvement of security professionals early in the design process. Security and usability shouldn’t be extra features introduced as an afterthought once the system has been developed, but an integral part of the design from the beginning.

Security professionals can provide input into the design process via several methods such as iterative or participatory design.[3] The iterative method consists of each development cycle being followed by testing and evaluation and the participatory method ensures that key stakeholders, including security professionals, have an opportunity to be involved.

References:

[1] S. L. Garfinkel and A. Shelat, “Remembrance of Data Passed: A Study of Disk Sanitization Practices”, IEEE Security & Privacy, 1, 2003, 17–27.

[2] John Maeda, The Laws of Simplicity, MIT Press, 2006.

[3] For iterative design see J. Nielsen, “Iterative User Interface Design”, IEEE Computer, 26(11) (1993), 32–41; for participatory design see D. Schuler and A. Namioka, Participatory Design: Principles and Practices, CRC Press, 1993.

Image by Rosenfeld Media https://www.flickr.com/photos/rosenfeldmedia/2141071329/


To find out more about the psychology behind information security, read Leron’s book, The Psychology of Information Security. Twitter: @le_rond


How employees react to security policies

8205162689_345cce5b75_o

Information security can often be a secondary consideration for many employees, which leaves their company vulnerable to cyber attacks. Leron Zinatullin, author of The Psychology of Information Security, discusses how organisations can address this.

First, security professionals should understand that people’s resources are limited. Moreover, people tend to struggle with making effective decisions when they are tired.

To test the validity of this argument, psychologists designed an experiment in which they divided participants into two groups: the first group was asked to memorise a two-digit number (e.g. 54) and the second was asked to remember a seven-digit number (e.g. 4509672).[1] They then asked the participants to go down the hall to another room to collect their reward for participating. This payment, however, could be only received if the number was recalled correctly.

While they were making their way down the corridor, the participants encountered another experimenter, who offered them either fruit or chocolate. They were told that they could collect their chosen snack after they finished the experiment, but they had to make a decision there and then.

The results demonstrated that people who were given the easier task of remembering a two-digit number mostly chose the healthy option, while people overburdened by the more challenging task of recalling a longer string of digits succumbed to the more gratifying chocolate.

The implications of these findings, however, are not limited to dieting. A study looked at the decision-making patterns that can be observed in the behaviour of judges when considering inmates for parole during different stages of the day.[2]

Despite the default position being to reject parole, judges had more cognitive capacity and energy to fully consider the details of the case and make an informed decision in the mornings and after lunch, resulting in more frequently granted paroles. In the evenings, judges tended to reject parole far more frequently, which is believed to be due to the mental strain they endure throughout the day. They simply ran out of energy and defaulted to the safest option.

How can this be applied to the information security context?

Security professionals should bear in mind that if people are stressed at work, making difficult decisions, performing productive tasks, they get tired. This might affect their ability or willingness to maintain compliance. In a corporate context, this cognitive depletion may result in staff defaulting to core business activities at the expense of secondary security tasks.

Security mechanisms must be aligned with individual primary tasks in order to ensure effective implementation, by factoring in an individual’s perspective, knowledge and awareness, and a modern, flexible and adaptable information security approach. The aim should therefore be to correct employee misunderstandings and misconceptions that result in non-compliant behaviour, because, in the end, people are a company’s best asset.

References:

[1] B. Shiv and A. Fedorikhin, “Heart and Mind in Conflict: The Interplay of Affect and Cognition in Consumer Decision Making”, Journal of Consumer Research,  1999, 278–292.

[2] Shai Danziger, Jonathan Levav and Liora Avnaim-Pesso, “Extraneous Factors in Judicial Decisions”, Proceedings of the National Academy of Sciences, 108(17), 2011, 6889–6892.

Photo by CrossfitPaleoDietFitnessClasses https://www.flickr.com/photos/crossfitpaleodietfitnessclasses/8205162689

To find out more about the psychology behind information security, read Leron’s book, The Psychology of Information Security. Twitter: @le_rond


The Psychology of Information Security – Resolving conflicts between security compliance and human behaviour

ITGP

In today’s corporations, information security professionals have a lot on their plate. In the face of constantly evolving cyber threats they must comply with numerous laws and regulations, protect their company’s assets and mitigate risks to the furthest extent possible.

Security professionals can often be ignorant of the impact that implementing security policies in a vacuum can have on the end users’ core business activities. These end users are, in turn, often unaware of the risk they are exposing the organisation to. They may even feel justified in finding workarounds because they believe that the organisation values productivity over security. The end result is a conflict between the security team and the rest of the business, and increased, rather than reduced, risk.

This can be addressed by factoring in an individual’s perspective, knowledge and awareness, and a modern, flexible and adaptable information security approach. The aim of the security practice should be to correct employee misconceptions by understanding their motivations and working with the users rather than against them – after all, people are a company’s best assets.

I just finished writing a book with IT Governance Publishing on this topic. This book draws on the experience of industry experts and related academic research to:

  • Gain insight into information security issues related to human behaviour, from both end users’ and security professionals’ perspectives.
  • Provide a set of recommendations to support the security professional’s decision-making process, and to improve the culture and find the balance between security and productivity.
  • Give advice on aligning a security programme with wider organisational objectives.
  • Manage and communicate these changes within an organisation.

Based on insights gained from academic research as well as interviews with UK-based security professionals from various sectors, The Psychology of Information Security – Resolving conflicts between security compliance and human behaviour explains the importance of careful risk management and how to align a security programme with wider business objectives, providing methods and techniques to engage stakeholders and encourage buy-in.

The Psychology of Information Security redresses the balance by considering information security from both viewpoints in order to gain insight into security issues relating to human behaviour , helping security professionals understand how a security culture that puts risk into context promotes compliance.

It’s now available for pre-order on the UK, EU or US websites.