Developers' Guide To Designing Secure Software

Introduction
In secure software design, one gets practical knowledge of how to design and develop secure software as well as insights on the significance of the role secure design plays during the Software Design Life Cycle (SDLC). This is done as an addition to fundamental security basics such as access control and encryption. There exist several principles in place to help guide developers on how to go along creating secure systems. Secure software and application principles are a collection of properties, behaviors, designs, and implementation practices that have possibilities to reduce the likelihood of threat realization and impact should that threat be realized.

Minimize the Number of High-Consequence Targets

1. Principle of Least Privilege

This principle recommends that accounts have the least amount of privilege required to completely perform their responsibilities. This principle applies mostly when a system contains sensitive information about an organization's clients or its internal records. Users are granted the minimum rights and permissions required to complete their tasks.

For instance, a person assigned to setting customers' appointments in a medical facility does not need access to all the customers' data; maybe the names, email or phone numbers, and appointment history. Information such as medical history and prescriptions should be accessed by the relevant personnel.

One of the core benefits of this privilege is to reduce the number of attack points by eliminating unnecessary privileges that can result in exploits and attacks. Further, it simplifies the collection of log information on illegal attempts to access resources where one is not permitted. The least privilege can be emphasized in hardware management, folder and file permissions, and database permissions.

For example, a student can only be given read access to a database and write access to a log file. In no account should a student have, delete privileges for certain databases, including academic performance or even read access to a server log file.

2. The Principle of Separation of Privileges, Duties, and Roles

This privilege is based on the fundamental rule that no single entity has the ultimate privilege or authority. This rule holds that no user or application has total control over a system, its components, and its resources. This ensures that entities are assigned roles or duties that require them to perform only a subset of the overall functions provided by the system.

For example, a developer will have access to the source code of a system, but he or she should not have access to the test phase feedback data. A developer can manipulate this information to green-light the software, even though bugs were detected. This will end up compromising the system after deployment. In the retail industry, a store attendant should not have the authority to issue discounts at will. This authority can be abused when the attendant issues discounts based on their relationship with the customer. In this case, the store manager should be allowed to approve any discounts given at the store.

Domain separations makes it easier to separate duties, roles, and privileges. Through domain separation, only entities perform the absolute tasks required, on the relevant data, using the required resources, using only the required functions to complete the task. This is known as the compartmentalization of users and data, which helps contain the impact of faults and failures.

Do Not Expose Vulnerable or High-Consequence Components

3. Keep Program Data, Executables, and Configuration Data Separated

Any systems' executables and configuration files are the most crucial. This makes them prone to attack attempts by exploiting possible vulnerabilities. This principle reduces the likelihood of an attacker gaining access to program data and files, and thereafter controlling and configuring them. One benefit of this separation is the reduction of software's high-consequence functions from its high-risk functions which are susceptible to attacks.

Further, it reduces the exposure of the software to malicious execution components or attacker-intercepted and modified environment data. It also reduces the exposure of data passed between the software and its environment.

For example, in modern operating systems, permissions are set such that a metadata file is readable to other applications. Further, a program's control data is only accessible to the file that created it. Further, for added security, software access controls and configuration data can be hosted on a trusted remote server.

4. Segregate Trusted Entities from Untrusted Entities

It reduces the exposure of high-consequence functions from its high-risk, vulnerable, and untrustworthy functions that are susceptible to the delivery of malicious scripts that compromise the software's efficiency and operations. All entities should be considered untrusted until verified. One of the benefits of this principle is to limit the potential for propagation of the impact and to minimize the damage that results from the execution of malicious code.

For example, programming languages contain security architectures that include sandbox functions and common language runtime. These functions assign the least privilege to executables within it. If an executable performs unexpectedly, an error is generated and the executable is prevented from accessing resources outside its sandbox.

5. Minimize the Number of Entry and Exit Points

Any software should have one entry point into its functions, modules, components, and processes. This principle advocates for the reduction of the number of software access points exposed to attackers hence reducing the attack surface area. In addition, it helps simplify software analysis and makes it easier to update or replace components. For example, an online platform may substitute a search function that is vulnerable to an SQL injection with a comprehensive navigation box built into the user interface.

6. Use Only Safe Interfaces to Access Environment Resources

This principle helps reduce the exposure of data passed between the software and its environment. Application-level programs are granted access to make direct calls to the OS, which creates a potential target for an attack. However, application-level applications should only make calls to application layer programs or explicit Application Programming Interface (APIs) to system resources. Further, system objects should be referenced correctly. Callouts and filename references should specify the full pathname of the resource being called. This eliminates the possibility of a wrong resource being accessed.

7. Assume Environment Data is not Trustworthy

The software designer should assume that all components of the execution environment are neither dependable nor trustworthy unless and until this assumption is proved otherwise. This practice reduces the exposure of the software to potentially malicious execution environment components or attacker-intercepted and modified environment data. The software should validate all environment data received before using that data. For example, application frameworks are verified to provide trustworthy environment data to the applications hosted within those frameworks.

Deny Attackers the Means to Compromise

8. Simplify the Design

This principle guides developers and secure systems analysts to keep the design as simple as possible. This will ensure that weaknesses and vulnerabilities are prevented from occurring, especially those that are hard to detect due to the complexity of a system. This is because security implications are hard to analyze and understand. For example, a developer can limit the number of states possible in software and leave out unnecessary features and functions.

9. Hold all Actors Accountable, Not Just Human Users

This practice ensures that all attacker actions are observed and recorded. This helps contribute to the ability to recognize and isolate attack patterns hence preventing attacks from succeeding. System auditing should extend to semi and fully autonomous systems that run with little or no human interference at all. For web services, security certificates and signatures provide a mechanism for service-to-service authentication.

10. Make Secure States Easy to Enter and Vulnerable States Difficult to Enter

This practice reduces the likelihood that a system or software will accidentally enter an exploitable state. The software should always begin and end its execution in a secure state. Any changes made should be deliberate more so from secure to vulnerable states. If options are made available in secure states, the software should be in a position to select the most appropriate one.

11. Design for Controllability

The design of the software should be able to make it resilient from the control of its execution. This makes it easier to detect attack paths and disengage the software from interacting with the attackers. For example, the software should include a feature to give it the ability to self-monitor and limit resource usage. Further, the software should be in a position to throw exceptions, errors and handle anomalies. It should also include a feature that gives feedback enabling validation of decisions before they are implemented.

12. Design for Survivability

This practice minimizes the amount of time a faulty or failed software component remains vulnerable to attacks. The design should enable software to take advantage of any redundancy and rapid recovery features. For example, the software should support automatic backups and should be modularized in such a way that its components can be decoupled and replicated on the spare platforms. Further, the included exception handler should be in a position to return the software to a known good state that is more secure than the failure state.