Add section on Threat Assessment, add headings

master
Jos Verlinde 2024-01-17 12:09:39 +01:00
rodzic c0f9c76dbb
commit b49eb82ea9
1 zmienionych plików z 50 dodań i 8 usunięć

@ -1,12 +1,54 @@
# Topics
* Frozen code
* Disabling the WebREPL
There are many ways to, and degrees of securing any computer system, and most of the options to improve security also have some sort of a downside. Either in speed, complexity to build, distribute or use the software, or in increased requirements to the hardware platform your solution needs to run on.
## Threat assessment and modeling
In order to be able to make a good or appropriate selection from the menu of security controls that you could apply, you will need to define what you want, or need, to secure against. After you know in enough detail the risks to secure against, only then you can start to apply the security controls to reduce that risk to a kevel that you or your users find acceptable.
While it is possible to do this on intuition, it can be difficult as often you need to think alternately as an attacker and as a defender.
According to the [Threat Model Manifesto](https://www.threatmodelingmanifesto.org/), the threat modeling process should answer the following four questions:
* What are we working on?
* What can go wrong?
* What are we going to do about it?
* Did we do a good enough job?
You do not need to start from scratch - there is a significant amount of documents and tools and videos that can help you do this.
But the best way to learn about threat modelling is by start doing it
## Responses
After risks have been identified, then responses to these risks need to be identified. Generally these are categorized as :
* Mitigate. Take action to reduce the likelihood that the threat will materialize.
* Eliminate: Simply remove the feature or component that is causing the threat.
* Transfer. Shift responsibility to another entity such as the customer.
* Accept. Do not mitigate, eliminate, or transfer the risk because none of the above options are acceptable given business requirements or constraints.
### Further reading
- [Threat Model Manifesto](https://www.threatmodelingmanifesto.org/)
- [Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html)
- [Awesome Threat Modeling](https://github.com/hysnsec/awesome-threat-modelling?tab=readme-ov-file#awesome-threat-modeling-)
- [Security for IoT](https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-iot/security/)
# Security controls that can be applied to MicroPython
## Frozen code
> Category: Reduces (not eliminate) the likelihood of someone tampering with your code
## Disabling the WebREPL
> Category: Eliminate any access via WebREPL
* `#define MICROPY_PY_WEBREPL 0`
* Disabling the Python compiler
## Disabling the Python compiler
> Category: Eliminates to option for a user to run code that has not been pre-compiled.
> Note: may also need to prevent a user to transfer css-compiled `.mpy` files to the MCU
* `#define MICROPY_ENABLE_COMPILER 0`
* Disable serial REPL access
* Secure physical access
* Port/vendor specific solutions
## Disable serial REPL access
## Secure physical access
Note: Securing pysical access with small devices likel MCUs is very hard. and an adigium in security is that "Physical access is the end of all security"
## Port/vendor specific solutions
* Encryption/Signing
* Minimise attack surface
## Minimise attack surface
* Shut down peripherals and network as much as possible