Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

10/27/2020
10:00 AM
Anita D'Amico
Anita D'Amico
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

5 Human Factors That Affect Secure Software Development

With the move to remote work, it's especially important to understand how to support, discourage, and monitor conditions for development teams.

Human factors are the psychological, physiological, and environmental properties that are both intrinsic to people and also influence their interaction with the world. Scientific evidence shows that certain human factors — such as fatigue, time of day, distractions, and even visual display formats — affect human performance and impact safety in industries such as aviation, trucking, healthcare, manufacturing, and nuclear power. 

The National Transportation Safety Board's investigative processes consider the human factors that contribute to an accident, beyond mechanical failures. The FAA's Dirty Dozen lists the 12 common causes of mistakes in the aviation workplace due to human factors. 

Related Content:

3 Ways Companies are Working on Security by Design

2020 State of Cybersecurity Operations and Incident Response

New on The Edge: What Is End-to-End Encryption?

Safety and security are closely linked; after all, security breaches can provide unauthorized access to safety-critical systems. You've probably read of attackers gaining remote access to medical infusion pumps or shutting down automobile safety systems. And software, which is a major component of most safety-critical systems, is notoriously insecure. 

What can software engineering learn from human factors research in safety-critical systems? 

Where App Security Meets Psychology
I set out to answer this question with my research partners at Secure Decisions and Rochester Institute of Technology. If we could identify the human factors that play a role in software security, then development managers could use that knowledge to reduce the accidental introduction of vulnerabilities in code. And security teams could locate code that was more likely to be vulnerable.  

We reviewed the scientific literature and conducted our own research. We looked at factors like team size, level of focused attention, physical separation of developers, time of day when code is written, and hours worked per day and assessed their relationships to vulnerabilities found in the software.

Through the research, we were able to identify a number of human factors that are associated with insecure software. With the move to remote work, it is especially important to understand the human factors that managers need to support, discourage, and monitor to create ideal working conditions for remote teams. Here is a high-level summary of some of our key findings. 

Developers Need Focused Attention 
Unfocused contribution rises when a developer is modifying multiple files or when the number of unique contributors to a file increase. Unfocused contribution is associated with a greater number of vulnerabilities. This suggests that development managers should think twice before assigning two many separate tasks to a single developer. And developers should situate themselves in an environment that is relatively free from distractions.

Bigger Teams Correlate to Less Secure Code
Larger teams mean more weaknesses and vulnerabilities. It’s hard to say what the ideal team size is. But research shows that Chromium files with 9 or more developers were 68 times more likely to have a vulnerability, and Apache web server files with 9 or more developers were 117 times more likely. So, my advice is to keep development teams relatively small and focused. 

Excessive Work Hours Affect Performance 
Research-based guidelines in aviation and medicine indicate that people engaged in safety-critical work should not work more than 11 hours per day. It is well-known that human performance degrades significantly as people work long periods of time. We should apply this to software developers and limit their sustained work to no more than 11 hours per day. Software "death marches" should be avoided not applauded.

The Time of Day Code Is Written Matters 
Code churned between midnight and 8 AM and noon to 4 PM have files with more vulnerabilities. This maps to our circadian rhythms, which are cyclical changes in our mental alertness and physiological arousal over the course of a day. Most humans' alertness wanes between midnight and 6 am, and many also sustain reduced alertness around 2 pm. It is prudent for software engineers to not code in the wee hours of the morning, and to take a break in the early afternoon.

Team Location Does Not Influence Code Security 
Research conducted by Microsoft found no difference in software security between teams in the same building, cafeteria, campus, locality, or even continent. Distributed teams and co-located teams had essentially the same number of post-release failures. This is good to know as we now live in a remote working environment. 

Studying human factors gives us a new way to identify source code that is more likely to contain vulnerabilities based on what we know about the developers and the teams that wrote the code. For example, analysts and developers could choose to first triage static analysis findings or perform code reviews on code that was built by a team of nine developers where most of the code was committed at 2 am in the morning. 

Understanding human factors is especially important as we develop new models for remote work. Managers could use human factors research to shape a remote work environment with fewer sustained work hours and fewer concurrent projects that in turn fosters more secure development practices.

Anita D'Amico, PhD is CEO of Code Dx Inc., which provides solutions that automate application security workflows within a DevOps environment.  Prior to becoming CEO, she led the development of innovative cybersecurity technologies for over 20 years, initially as the head ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Commentary
Ransomware Is Not the Problem
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  6/9/2021
Edge-DRsplash-11-edge-ask-the-experts
How Can I Test the Security of My Home-Office Employees' Routers?
John Bock, Senior Research Scientist,  6/7/2021
News
New Ransomware Group Claiming Connection to REvil Gang Surfaces
Jai Vijayan, Contributing Writer,  6/10/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Zero Trust doesn't have to break your budget!
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-36388
PUBLISHED: 2021-06-17
In CiviCRM before 5.21.3 and 5.22.x through 5.24.x before 5.24.3, users may be able to upload and execute a crafted PHAR archive.
CVE-2020-36389
PUBLISHED: 2021-06-17
In CiviCRM before 5.28.1 and CiviCRM ESR before 5.27.5 ESR, the CKEditor configuration form allows CSRF.
CVE-2021-32575
PUBLISHED: 2021-06-17
HashiCorp Nomad and Nomad Enterprise up to version 1.0.4 bridge networking mode allows ARP spoofing from other bridged tasks on the same node. Fixed in 0.12.12, 1.0.5, and 1.1.0 RC1.
CVE-2021-33557
PUBLISHED: 2021-06-17
An XSS issue was discovered in manage_custom_field_edit_page.php in MantisBT before 2.25.2. Unescaped output of the return parameter allows an attacker to inject code into a hidden input field.
CVE-2021-23396
PUBLISHED: 2021-06-17
All versions of package lutils are vulnerable to Prototype Pollution via the main (merge) function.