All organizations, including governments, are software organizations nowadays. Software is infrastructure – it powers nearly every organization around the globe. It’s just as important to all types of organizations across all industry verticals such as power, transportation, and finance.

Consider, for example, the shipping giant Maersk. Shipping is about moving things from one place to another. It’s about ships, and cargo containers, and trucks, and logistics.

But shipping is also about software.

Like many other organizations, Maersk relies on software for communication, for scheduling, for billing, for planning and analysis, and many other functions. A malware attack in 2017 brought the global operation to a standstill, costing an estimated 300 million US dollars. Heroic efforts by Maersk employees restored operations, but part of the problem was that Maersk, like so many other organizations, was not prepared for this kind of disaster.

Risk Management

Risk management is an essential element of any organization. It’s also an element that is often overlooked.  Human nature is to look to what is possible, to build something that works quickly without considering the risks. Software is fertile soil for this build-first-and-ask-questions-later approach. Applications are frequently built with functionality as the primary goal.

Prudent organizations periodically analyze potential risks to organizational assets, then make plans and put mechanisms in place to minimize those risks. One risk is losing key personnel, due to illness, death, or getting a new job. One policy to counter that risk would include restricting how many organization leaders can share an airplane ride. Likewise, plans for operational continuity in case of lost personnel can help mitigate the impact of such events.

A comprehensive risk management program looks at potential events and ranks them according to their likelihood and impact. Some of this analysis is based on history, and some is based on guesswork. An extinction-level asteroid impact is a low-probability, high-impact event. Severe weather events can be high-probability (depending on location), high-impact events.

Based on ranking, mitigations are applied using available resources, and recovery plans are put in place.

Recovery and Continuity

Key components of risk management include disaster recovery planning and business continuity planning. Continuity planning allows a business to define elements of a response such as who is in charge, how communication of the incident occurs, and whether additional tasks are required to limit the impact of the incident. If you don’t plan ahead, addressing these items during an incident only increases stress levels within teams that could lead to critical details of the incident being accidentally deleted, overwritten, or delayed.

Consequently, failures in software due to accident or malice can have catastrophic results. For this reason, disaster recovery planning should include the very real possibility of software failure. Hopefully, you are already planning response to severe weather events and other large-scale threats. Make sure you are including large-scale software failure as a viable scenario as well.

Software and its associated risks must be factored into risk management. Software is part of the critical infrastructure for every organization; software risks must be analyzed and addressed, just like any other types of risk.

Layered Defense and Planned Response

The software-related assets that need protecting are the functionality provided by software and the data that it uses.

Ransomware is a good example of a threat that denies availability of functionality (the organization cannot use its computers) and data (the organization cannot access its own data). From a risk management perspective, how would you mitigate the threat of ransomware?

  1. Perform thorough security evaluations of software during the procurement cycle.
  2. Educate users on malware and other threats and good security hygiene.
  3. Keep software up to date.
  4. Back up data reliably.

In this simplified list, items No. 1-3 lower the likelihood of a ransomware incident, and item No. 4 lowers the impact of a ransomware incident.

With some modest investments, you have lowered the probability of a ransomware incident. If it happens anyhow, you have the backups you need and a plan in place to restore your normal operations quickly, minimizing the cost of such an incident.

This is just one example of how risk management can help you handle software troubles. A comprehensive analysis would include many other threats:

  • What if our cloud provider is down?
  • What if our payment processor is down?
  • What if our data center is knocked offline by a storm?
  • What if a disgruntled insider attempts to disrupt our operations?
  • What if a vendor accidentally introduces a bug into our billing system?
  • … and so on

Security is Inseparable from Software

At the same time, making security part of every phase of procuring, deploying, operating, and maintaining software minimizes the risk of failure.

Once upon a time, organizations treated software and security separately. The information technology (IT) team was responsible for procuring, deploying, and maintaining software for the rest of the organization, while the security team performed audits and made suggestions to the IT team.

For organizations that create software, either as a product or for internal use, the security team would typically run application security tools on nearly complete applications, reporting findings back to development teams. This led, inevitably, to overworked, behind-schedule security teams and exasperated development teams.

Time has taught us that security and software cannot be separated. It makes no sense to create applications without having security be part of design, implementation, and testing, just as it makes no sense to create airplanes without having safety be part of design, implementation, and testing.

Even when buying off-the-shelf software, deploying it, operating it, and maintaining it, security must be part of every aspect of using software. If you buy a database in which to keep all your customer records, you must bake security into every step of installing, configuring, and using that database. The continual parade of news stories about this or that unsecured cloud database shows that organizations are building functionality without having a firm grasp on security. Such an approach is risky and can be punishingly expensive.

Software is Infrastructure

A comprehensive, security-first approach to software is the best way to manage risk.

When building software, organizations should follow a secure development life cycle (SDLC), in which security is part of every phase. In the design phase, activities such as threat modeling help architects and designers think about various threats and how to mitigate them. (In this respect, it is much like a more focused risk analysis activity.) During implementation and testing, automated application security testing (AST) tools help development locate and remediate weaknesses in the software as it is being built. Static analysis and software composition analysis (SCA) tools help locate weaknesses in the source code and third-party components of an application. Fuzzing, interactive testing, and other types of dynamic testing can be used during software testing to uncover and fix weaknesses. During software release and maintenance, SCA monitors the third-party components of an application so developers can proactively respond to newly found vulnerabilities.

When buying and operating software, organizations should again use a security-first approach. Armed with knowledge of how an SDLC should function, they can ask vendors about security processes and perhaps examine results of application testing tools. In additional, procurement teams can perform their own analysis of potential applications to evaluate their security posture before purchase. Processes for deploying and operating software should have similar rigor, with security a consideration at every phase.

Encompassing both the building and buying of software is an overarching security mindset. Driven by the highest levels of leadership, organizations can develop a security-first culture, supplemented by security education for all employees.

By extending traditional risk management methodologies to include software, organizations can lower their overall risk of catastrophic events. If catastrophe happens anyway, recovery and continuity plans mean that the impact is as small as possible.

Software is infrastructure for all types of organizations. Give software a seat at the table of risk management to minimize the probability and impact of software incidents.


Jonathan Knudsen

Jonathan Knudsen is a senior security strategist for Synopsys Software Integrity Group. He likes to break things. He has tested all kinds of software, from network infrastructure and medical devices to cryptocurrency nodes. Knudsen has worked as a developer, consultant, and author. He has published books about 2D graphics, cryptography, and Lego robots, and has written more than 100 articles on a wide range of technical subjects.

The Ties Between Business Continuity and Classic Rock
Mission-Critical Applications Correlate With a Strong Safety Program Safety is related to business continuity, but this connection may not be...
Business Email Compromise: A Guide to Protecting Yourself After a BEC Attack
Many businesses underestimate the impacts of business email compromise (BEC). It doesn’t cause shutdowns or immediate loss of productivity and...
Career Spotlight: Chelsea Selbig
Tell us about yourself – your name, company, title, and responsibilities? Chelsea Selbig I’m Chelsea Selbig, a senior business continuity...
Post-COVID Recovery Calls for a Renewal of Knowledge Management
In an effort to grasp the knowledge of executives throughout North American in a post-COVID-19 world, leaders from large corporations...