This is the continuation of the course Secure Coding in Software Engineering.
- Go to Home.
- Go to next chapter.
Almost every gadget around us uses software to operate, whether it be a hearing aid or an MRI machine. Software plays a major role in making every gadget operational and useful for its respective task. A lot of resources go into making the software work. But not enough attention is given to the software being safe, secure, behaving correctly, effects on other parts of the system(s). Yet, still somehow software still works.
Some of the reasons for the software being insecure
- Poor communications (between all parties involved)
- Commercial pressures
- Poor system design
- Poorly defined system requirements
- Inaccurate estimates of required resources
- Unmanaged Risks
- Sloppy Development Practices
- Use of immature technologies
- Stakeholder politics
and many more... [1]
Importance of Secure Software Systems
What are the repurcussions of an insecure software or a software failure?
While it might not seem like a big deal, software failures can have serious consequences. Here are some events that illustrate this:
- Injury & Loss of Life [2]
- Loss of financial assets [1]
- Loss of resources: organizational assets [3], the organization itself [1].
- Loss of the software system: Denial of service
- Loss of valuable or sensitive information
- Loss of trust*
*The trust factor is not measurable but has a direct impact on the application usage.
And if the bugs were not enough, there are active adversaries trying to exploit vulnerabilities in software systems. These adversaries are:
- Well-organized, similar to small businesses
- Well-resourced, ranging from organized crime to nation states
- Sophisticated in their technical abilities and attack methods
Source: The Different Types of Hackers and Their Motivations: An Overview
How do we identify the risks?
To identify the risks, one must look at the attacks.
Mitigations for Insecure Software
There are ways in which a couple of reasons for software being insecure mentioned above can be mitigated.
- Poor System Design
- Giving a thought to security during the system design.
- Unmanaged Risks
- Identifying security risks beforehand.
- Sloppy Development Practices
Certain measures can be put in place to prevent such practices, including but not limited to:
- Software Development Guidelines
- Software Lifecycle Management
- Code Review Process
What about using crypto, or anti-virus, or any other kind of Security Features?
"Security Features" are not the answer. Just by using Anti-virus, Crypto, Implementing your own Cryptographic Algorithm, using Open Source Software, or any other kind of Security Software is not going to provide you with a solution.
Furthermore, security through obsecurity is also not the answer to the problem. Like adding barriers is not going to stop a user from finding other ways to bypass the system, thus, making it more insecure (CWE-655). The situation can develop a loss of trust within the user and the software system.
Source: https://youtu.be/pqyFG-G4hF8?si=lt4FKxSA1dROA1J4
There is a trade-off between Security and usability/convenience. Interestingly, new ways are being explored to find a balance in usable security.
Measuring Security
There are a lot of places where one can retrieve information around the vulnerabilities. These location contain an extensive and actively updated information around the defects within the code.
- CISA Cybersecurity Advisory, https://www.cisa.gov/news-events/cybersecurity-advisories
- Debian Security Tracker, https://security-tracker.debian.org/tracker/
- National Vulnerabilities Database/CVE, https://nvd.nist.gov/general/nvd-dashboard
- MITRE CVE Database, https://cve.mitre.org/
Common Weakness Enumeration (CWE)
The common weaknesses enumeration defines common weaknesses in software that have security implications. This is a language that communicates the root cause of the vulnerability.
Difference from vulnerabilities:
- Weaknesses can be thought of as mistakes or flaws (intentional or unintentional) in the software that can have serious system level impacts.
- Vulnerabilities allow adversaries to take advantage of accessible weaknesses that are exploitable in order to achieve their attack goals.
For example, when a vulnerability says that it is a buffer-overflow, that sentence in itself is useful only to a certain extent. Was it a out of bounds read/write? CWE can be attached to the vulnerability that will help in explaining why the vulnerability occurred. Try looking up CWE-125 or CWE-787 for more details.
What about Cross-Site Scripting (XSS)? Is it an attack or a weakness?
The XSS is an attack, at heart of which lies a weakness termed Improper Neutralization of Input During Web Page Generation (CWE-79).
Similarly, SQL Injection is an attack which is caused by Improper Neutralization of Special Elements used in an SQL Command (CWE-89).
While going through a CWE, you will see a section covering consequences. The heading in the page is Common Consequences and they describe the impact on the application if the weakness is not fixed. However, not all the technical impact will be accurate to the application being addressed. It is upto the security personnel to educate the developer, what will happen if the weakness is not addressed.
Weakness Inception within Software
The following diagram shows the different layers of software over the operating system.
The weakness can exist anywhere along these layers. The criticality of the weakness increases from top to bottom. If there is a weakness within the Hardware, then it is extremely difficult to mitigate it as upgrading hardware is not easy. In contrast, upgrading an application is much easier due to the availability of internet and in-place upgrade mechanisms within the software. As a software developer, one has to think about all the aspects of each layer while writing a software.
Each level of the software model incurs a security review. For example, in requirements phase, having a documentation is a step. However, if the documentation for some reason is incomplete/inconsistent, then it is a security risk (CWE-1112, CWE-1059, and more.). The security impact is indirect in this case as issues with documentations are primarily quality focused. This doesn't mean that one should never write any documentation, rather address the important or critical aspects of the application being developed.
A majority of the weaknesses are found in the implementation phase, but they can be traced back to the requirements phase.
Is it possible to write secure code at all?
The answer is Yes. Developers don't share how one can write secure code due to various reasons, some of them being, insufficient understanding of the concepts, company restrictions, insufficient documentation (except in their minds), etc. CWE can help with that. It is designed to assist the developer in writing secure code and sharing it with their peers and public.
One thing to note is what the CWE doesn't do is observing the human processes like in an organization or processes like for example, if the company doesn't have a security policy, there is no mapping within CWE to address it.
Secure Development Lifecycle
An organization level of security risk can be addressed by following a secure development lifecycle. It encapsulates a software model with security findings. Some examples of Secure Development Models are:
- Building Security In Maturity Model (BSIMM) - https://www.synopsys.com/software-integrity/software-security-services/bsimm-maturity-model.html
- Software Assurance Maturity Model (SAMM) - https://owaspsamm.org/
- Microsoft Security Development Lifecycle (SDL) - https://www.microsoft.com/en-us/securityengineering/sdl
To pick one, Microsoft has built the SDL for internal use and have provided information publicly to everyone on how to proceed in different stages:
Source: https://learn.microsoft.com/en-us/archive/technet-wiki/t/resources/5554.sdl_5f00_steps.jpg
Governance and Education Phase - Security Training
Training the developers is the key, especially in secure coding practices. A training should be focused on:
- Secure Design
- Threat Modeling
- Secure Coding
- Security Testing
- Privacy analysis
- Policy and Governance guidelines
Requirements Phase
This phase is used to establish the security requirements of the entire software system. A Security Risk Assessment[4] and a Privacy Risk Assessment[5] can help to identify which functions of the software need to be closely looked at.
For example, if the software stores personal information, the functionality of the software that governs stores, transmission and uses should be examined closely and requirements such as
HIPAA rules should be applied to determine what security requirements should be put in place.
What is the minimum criteria that must be met in order to pass the quality or security of the software system for a release?
For example, no vulnerabilities marked critical should be present in the release.
Once the minimum criteria is set, it should not be relaxed or compromised. Getting this agreement ahead of time from stakeholders can help establish the criteria.
Design Phase
With the security requirements in hand, the design phase can proceed accounting for those additional security requirements. The design requirements outline the plan for the project to follow through the rest of the phases.
The security requirements should not be thought of as an add-on. The security requirements should be "baked-in" to the design of the software system. Especially with cryptographic functionality, the design requirements should account for what, how and why the minimum cryptographic requirements should be used.
Attack Surface analysis/reduction and Threat modeling is generally performed during this phase.
Implementation Phase
The implementation phase of the security development lifecycle is focused on how the software system is planned to be developed, deployed and used. This includes all the documentation and tools geared towards the goal above.
This phase generally involves identifying and using only an approved list of tools, security checks etc. It also involves deprecating unsafe functions of the software system and performing static code analysis.
Verification Phase
The verification phase acts as the phase where you are able to check and verify whether the security requirements were really met in the implementation. A public release security and privacy review can be performed during this phase. This may also include any consultations with institutional review boards.
Dynamic Analysis techniques are used to test the software system as it runs. Fuzz Testing techniques are also used to ensure no failures due to random input result.
An attack surface review is performed to ensure any and all attack vectors have been addressed as a result of any changes in the previous phases.
Operations Phase - Release and Incident Response
I am just a coder... Who cares after the code is releases? #amiright
This is a critical part of the lifecycle.
The Release phase is used to ready the software system for consumption by customers. A final security and privacy review is performed. Licensing of the software and its terms and any servicing terms for third-party software are put in place. Release archiving is performed storing all source code, documentation, specifications, design (including security) documents are archived.
An incident response plan is put in place including any Emergency response plans for the software system.
Detailed description of each step is available at Microsoft's SDL[6].
References
The references are provided as URLs, however, if the original content is for some reason not accessible then the information is recorded as a copy of the original content under docs/references.
- Why software fails? (2005) by Robert N. Charette
- Medical Devices: The Therac-25* by Nancy Leveson
- Analyzing Software Failure on the NASA Mars Climate Orbiter (2017) by Christopher Demicoli
- What is Security Risk Assessment and How does it work? by Synopsys
- What is Data Privacy Risk Assessment and Why is it Important? by Privacy Pillar
- The Security Development Lifecycle by Microsoft
Top comments (0)