CyberSecurity Part 2: NIST’s Principles and Best Practices for Secure Software Development


AI-Powered Chatbots in Customer Service and Engagement

Using AI for customer service in your company is a definite method to save time and money. If you’re like most business owners, you’re constantly searching for fresh, creative ways to improve your enterprise. We’re here to inform you that improving AI customer service is a simple and rapid win.

Read More »

As we are about to see an industry-wide redoubling of efforts on secure software development, this is a good time to point you in the direction of essential resources offered by the National Institute of Standards and Technology. Beyond recent cyberattacks and more remote work, it’s anticipated that the Payment Card Industry Security Standards Council will release PCI DSS v4.0 in Q1 of 2022. It is likely to increase standards for virtually all eCommerce software. Like reusing good code, it’s not always necessary to reinvent the wheel. Most organizations will be playing catch up with NIST’s frameworks. Those wanting more can add to it.

Benefits of Secure Software Development - The Carrot

No one in their right mind is going to tell you that secure software development is easy. It requires extra effort. You’re competing with what probably amounts to a lot of amateur hackers, but also groups of dedicated Black Hat professionals. Some of them are backed by corrupt states – the usual suspects. They stand to profit if they can penetrate your systems. Conversely, it’s hard to think of a case where anyone really increased their profitability with secure software.

Leastwise, we can start with the top-level benefits of keeping your software secure:

  • Minimizes risks of your system being compromised.
  • Mitigates data theft so hackers can’t read or use the files they steal.
  • Reduces costs by catching vulnerabilities when they are easier and faster to fix.
  • Provides continuous practice and training for software developers.
  • Develops customer trust by showing that you’re serious about security.

Of course, that all sounds nice. It’s really quite debatable whether any of these reasons will inspire your C-levels to make a serious commitment to securing your software. As of 2020, according to Verizon, only 27.9% of companies were fully compliant with the current PCI standards. These companies recognize one other benefit associated with secure software development:

  • Complies with regulations to avoid fines and penalties!!!

And the Stick

In a world where companies cease striving “to not be evil” – it’s always good to put a dollar figure to everything. Feel free to convert to Euros, Sterling, Francs, and seashells, if you like.

Let’s take a quick look at some of those fines and penalties.
Violations of the EU’s General Data Protection Regulation (GDPR) can result in fines of up to €20 million or 4% of annual global revenue, whichever is highest. Two examples of many – Google incurred €50 million in fines; Marriot €20.4 million.

In 2020, Premera Blue Cross was fined $6.85 million by HIPAA for a data breach involving the records of 10,466,692 individuals.

The Payment Card Industry can impose fines on non-PCI compliant merchants of up to $500,000 per incident for security breaches. Costs of notifying customers of breaches plus costs of recovery can push costs much higher though. It cost Equifax at least $575 million, and Target at least $292 million.

Then there’s the ransomware attacks – where CNA Financial paid $40 million. It makes all of the attention on Colonial’s $4.4 million payout seem trivial, if not for making national news and forcing responses in Whitehouse press conferences… and threatening gas supplies to entirety of the US eastern seaboard.

NIST’s 33 Principles of Secure Software Development

Though dated (2004), NIST’s Engineering Principles for Information Technology Security remains equally true today, the principles haven’t changed. Below, all 33 principles of secure software development are listed verbatim, deserving all of the attention they can get. One is to wonder, if all of these principles were followed how many critical cyberattacks could have been prevented?

Security Foundation:

1. Establish a sound security policy as the “foundation” for design.
2. Treat security as an integral part of the overall system design.
3. Clearly delineate the physical and logical security boundaries governed by associated security policies.
4. Ensure that developers are trained in how to develop secure software.

Risk-Based Principles:

5. Reduce risk to an acceptable level.
6. Assume that external systems are insecure.
7. Identify potential trade-offs between reducing risk and increased costs and decrease in other aspects of operational effectiveness.
8. Implement tailored system security measures to meet organizational security goals.
9. Protect information while being processed, in transit, and in storage.
10. Consider custom products to achieve adequate security.
11. Protect against all likely classes of “attacks.”

Ease of Use

12. Where possible, base security on open standards for portability and interoperability.
13. Use common language in developing security requirements.
14. Design security to allow for regular adoption of new technology, including a secure and logical technology upgrade process.
15. Strive for operational ease of use.

Increase Resilience

16. Implement layered security (Ensure no single point of vulnerability).
17. Design and operate an IT system to limit damage and to be resilient in response.
18. Provide assurance that the system is, and continues to be, resilient in the face of expected threats.
19. Limit or contain vulnerabilities.
20. Isolate public access systems from mission-critical resources (e.g. data, processes, etc.).
21. Use boundary mechanisms to separate computing systems and network infrastructures.
22. Design and implement audit mechanisms to detect unauthorized use and to support incident investigations.
23. Develop and exercise contingency or disaster recovery procedures to ensure appropriate availability.

Reduce Vulnerabilities

24. Strive for simplicity.
25. Minimize the system elements to be trusted.
26. Implement least privilege.
27. Do not implement unnecessary security mechanisms.
28. Ensure proper security in the shutdown or disposal of a system.
29. Identify and prevent common errors and vulnerabilities.

Design with Network in Mind

30. Implement security through a combination of measures distributed physically and logically.
31. Formulate security measures to address multiple overlapping information domains.
32. Authenticate users and processes to ensure appropriate access control decisions both within and across domains.
33. Use unique identities to ensure accountability.

A Secure Software Development Framework

Highly recommended download: Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF) by Donna Dodson, Murugiah Souppaya, and Karen Scarfone, was updated in April of 2020. Complimenting the principles, this framework details secure software practices and tasks to prepare your organization, protect and produce well-secured software, and for responding to vulnerabilities. It provides examples and a list of references for each task.

Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality (PW.4):

Lower the costs of software development, expedite software development, and decrease the likelihood of introducing additional security vulnerabilities into the software. These are particularly true for software that implements security functionality, such as cyptographic modules and protocols.


Acquire well-secured components (e.g., software libraries, modules, middleware, frameworks) from third parties for use by the organization’s software.

  • Review and evaluate third-party software components in the context of their expected use. If a component is to be used in a sustantially different way in the future, perform the review and evaluation again with that new context in mind.
  • Establish an organization-wide software repository to host sanctioned and vetted open-source components.
  • Maintain a list of organization-approved commercial software components and component versions.
  • Designate which components must be included by software to be developed.

BSA: SM.2, SM.2.1

IDASOAR: Fact Sheet 19

MSSDL: Practice 6


SCTPC: 3.2.1

SP80053: SA-12

SP800181: K0039



Secure Software Development Best Practices

In our previous article about President Biden’s Executive Order on CyberSecurity (and with NIST, generally), we talked Software Bill of Materials, Tracking Vulnerabilites and Patches. The documents and principles are a comprehensive source of secure software development best practices. Like initially noted, it’s not necessary to reinvent the wheel. We can add to the wheels, and so there are a few SSD best practices deserving of extra notes.

Exercise the Principle of Least Privilege

Only provide people, user accounts, and the software itself, the privileges (or access) to what they need to do their jobs, roles, and functions. It can apply to every level in a system from the OS to the network, databases, and applications. This can also extend to the physical environment, for example only letting authorized personnel in the SNOC or only if they are accompanied by a supervisor. Employees are actually responsible for an estimated 40% of data theft – and typically when they are about to change jobs.

So, one area of risk is not actively managing PoLP and removing permissions if an employee’s role changes or even when they do leave the company. Somewhat related is that while many companies rightfully insist on nondisclosure agreements (NDAs), far too many fail to “secure” (hardware, software, hard copy) materials provided to team members on their departure. Google Docs is one system rife with people continuing to have access to files… forever.

Use Linters or Static Code Analysis Tools

In addition to frequent testing, use a linter or a static code analysis tool to help catch defects before creating pull requests. Linters and static analysis can detect memory leaks, array or string overruns, access violations, etc. A linter can also help enforce style guide rules, make code easier for everyone on the project to read, and keep code reviews on task.

Test Early and Test Oftenly

Oops, made a mistake – will keep it there, but it’d take one second to delete that erroneous “ly.” It’s fast, easy, and there’s no real cost when developers fix errors while they’re writing code. Testing code as it’s written also makes debugging fast and efficient because developers have the code fresh in mind. After this point, however, the cost of finding and fixing defects begins to quickly increase.

Penetration Testing

Penetration tests or pen tests are simulated cyberattacks against your system to find vulnerabilities. Several regulations (GDPR, HIPAA, SOX, the PCI DSS, and others) require directly reference periodic risk assessments and/or penetration tests. It’s generally understood that a risk assessment includes a penetration test. Again, all eCommerce software is likely to be impacted by PCI DSS v4.0 which is expected to be released in Q1 of 2022.

In most cases, regulations have required that a pen test or risk assessment yearly and/or following any significant changes to the system. Gradually, more organizations are conducting penetration tests more frequently. A wide range of software penetration tools are available. However, more and more companies are making use of bug bounty organizations like BugCrowd and HackerOne, or creating their own programs like Microsoft, Facebook, and Intel.

CyberAttack Data Sharing

As defined by Biden’s Executive Order, we can expect to be required to share a lot more data should our systems get hacked. Checkout Section 2 of EO 14028. I’d draw attention to:

(c) The recommended contract language and requirements described in subsection (b) of this section shall be designed to ensure that:
(i) service providers collect and preserve data, information, and reporting relevant to cybersecurity event prevention, detection, response, and investigation on all information systems over which they have control, including systems operated on behalf of agencies, consistent with agencies’ requirements;

That is worthy of a post unto itself, suffice that the actual requirements of the EO will trickle out through May of 2022. It’s likely that we’ll cover more on secure software development over the coming year, and where possible and appropriate, we’ll include news about the “latest paperwork.” In the meantime, we can be thankful that NIST won’t be using nude body scanners to ensure software developers aren’t a security risk.

Automate Your Software Development Metrics

Gitential makes it easy for you to automatically track critical performance metrics with four levels of visibility – company level, by project, team, or individual. You’ll have on-demand access to comprehensive statistics across the four main drivers of software development – productivity, efficiency, quality, and teamwork. With this data, you can begin measuring the benefits of teamwork in software development, identify what’s holding your team back, improve cycle time, and more.

Did you like our content?

Spread the word

Subscribe to Our Newsletter

Don't miss our latest updates.
All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.

Did you like our content?

Spread the word

Subscribe to Our Newsletter

Don't miss our latest updates. All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.