3.0 KiB
Executable File
| tags | |
|---|---|
|
What are we doing:
Create a documentary program that allows models of systems from both the digital and physical world to interact. Allow engineers from both disciplines to create models of their own systems and not have to worry about the other guy, except for explicitly stating the links.
These links are very important. This management software will handle all of these links and components and create a proof / security management system. These links (and components) will upon creation create work ticket that demands strict definitions of what their function is, and require proof to be provided about can happen in that channel. Prove things about what messages can be sent and what data can be communicated.
The individual components in these systems will also have proofs required of them. Each component needs proof about how it handles messages inside and out of these links.
The third critical process is the analysis possible of viewing one component and how it connects. Call it a connectivity tree. This is like an advesary POV. If you start at one point, how can you as an adversary move around the system. This can also be like a reverse pov. If you’re the control system, how can an adversary come get to me?
This doesn’t change the fact that the proofs still need to be made and requirements and specifications can still be a problem, HOWEVER, this kind of a system discretizes the components such that teh proofs are smaller. You only need to prove each piece, and each interaction. You do not need to make proofs about the whole system.
This is kind of like building a brick wall. You have several bricks, you don’t say something about the security of the whole wall at once, you can examine each brick and if you’re sure each brick is secure, and the mortar between them is quality, then you can say something about the wall itself.
Why are we doing this:
People just cannot communicate. There is a void is saying where people can communicate about these issues. There are conflicts about communication, what is a model, what is a system. This allows these different disciplines to get into the pieces that they’re good at, while providing a way for everyone to understand how their system is connected to everyone else.
Different systems also have different ways of accepting “proof”. Communications need formally proven. The hardware of a controller needs proven formally. The control laws themselves? Well they don’t really need formally proven. Those systems don’t really need to go deeper than the controls engineering that has happened to create them.
Notes about task:
Keep breaking down components and don’t allow a larger component to be “secure” unless all sub-components are mitigated or proven as safe.
Enforce peer checking
Write requirements / specs in English AND proof language. Part of peer checking job is to ensure these align.
Sign proofs to program versions. Cannot update unless new signed proof exists
Need to discuss with Dan Robert n co.