[agl-discussions] RFC - Security Framework for AGL

[Dominig ar Foll (Intel OTC)]

Le 22/09/2015 09:37, Jeremiah Foster a écrit :
>
>
>
> Please forgive me if this sounds like a rant, I really do not want to 
> rant, but I hold some fairly strong opinions regarding security. It 
> really won't fit into a couple of SAT discussions. If, as the cliche 
> goes, security is a culture, then security needs to be thought of 
> during the design phase of a given system. It is an anti-pattern to 
> rely on patches later. You want the system architects to be able to 
> understand their domains well enough so they can spot security holes 
> in the design phase. Look at the design and implementation of kdbus 
> for example, that is the kind of security posture you need to have to 
> ensure security is designed into the system.
Unfortunately since along time "Perfect is the enemy of Good" (extract 
from Voltaire Dictionary of philosophy 1770), trying to cover everything 
is not a viable security model.
If you want to succeed, I would advise to start some very simple bases 
that you enforce at low level when starting the implementation and then 
build on top. So far I a have used quite successfully on several secured 
project the two initial starting motto to build the architecture:
   - only what is explicitly allowed is possible (white list model)
   - secured SW software update is possible even on a compromised system.

The KDbus is a good example of a project which has been about to succeed 
to make in the up streamed kernel form more than 3 years but is still 
not in. Further more as it has missed 4.1 it will not be in this year 
LSTi so fore many of us that means out for all 2016 at least. I am 
afraid that while security is important, time to market is also 
critical. I personally always try to remain very pragmatic.
>
> Also, there needs to be discussion on many more topics than just a MAC 
> tool. Security will require experts, in both automotive and GNU/Linux, 
> who can elucidate best practices and proper, testable configuration. 
> You'll want to have an interface to the HSM that is as hardware 
> independent as possible, up to date information on ciphers and HMAC 
> algorithms, PKI, vulnerability reporting, bug embargo policy, 
> responsible disclosure policy, intrusion detection, a threat model, 
> and path to mitigation when exploits and/or privilege escalation is 
> found. There is no alternative to a holistic security discussion since 
> missing one piece may lead to catastrophic failure.
The most obvious starting point is to reduce the surface of attack what 
can be done greatly by white listing services and access (most often 
with a MAC) as well as  insuring the integrity of the system and the 
cypher block.
In the later HW helpers even if not portable are the most efficient 
solution.

One practical model that could work for AGL is to slice the problem. I 
share with you the list that I use when I start a project.

  - Trusted Boot and GW chain of trust
  - Integrity of the SW in operation
  - white listing service and resources access
  - process and application containment
  - SW update process.
  - Code static analysis
  - Compiler and tool secure option enforcement
  - Test and validation.

The other issue such as closed reporting and embargo are coming far 
later and to be honest are more process hygiene rather than architecture 
issues.

One thing is sure if AGL architects do not want to be shamed and their 
companies in trouble, when the next million+ cars ,security related call 
back will come (I have no doubt it will happen again), you better start 
to implement the base now and work the details later.

Regards

-- 
Dominig ar Foll
Senior Software Architect
Open Source Technology Centre
Intel SSG