initial version of the AGL security blue print Chap 1,2, and 3

Signed-off-by: Dominig ar Foll <dominig.arfoll@fridu.net>

1 files changed, 131 insertions, 2 deletions

diff --git a/sec-blueprint/01-overview.md b/sec-blueprint/01-overview.md
index a9f6d95..8b102cf 100644
--- a/sec-blueprint/01-overview.md
+++ b/sec-blueprint/01-overview.md
@@ -13,10 +13,139 @@ layout: techdoc
 1. TOC
 {:toc}
 
-## Introduction
+##Introduction
+###Abstract
+
+
+This document describes how it is possible to create reasonably secured
+connected cars using already available Open Source components. The
+complexity attached to such project is clearly exposed for each step and
+may seem a quite heavy reading. Fortunately ready made solutions are
+coming on the market (Open Source and Proprietary), enabling short cuts
+for many of us.
+
+The documentation mostly focusses on the embedded side of the problem leaving the cloud
+components and manufacturing processes for further study.
+
+### The risk is real
+
+Connected cars, to be accepted by users and keeping under control
+liability of the Automotive Industry will have to solve many issues
+ranging from physical, direct, and remote and indirect cloud attacks. A
+large section of unsolved technical security challenges, lies in car
+connectivity to user owned devices and well as to cloud.
+
+The Automotive Industry, by opposition to those operating in cloud and
+mobiles businesses, has little experience of security issues and no long
+return of experience. Proven solutions derived from the IT world are for
+most of them, inapplicable.
+
+For many people the Cyber Security risk for the Automotive industry is
+still at best not understood and unfortunately more often, simply
+ignored. If the Fiat-Chrysler cyber car jacking has forced the industry
+to open their eyes, it is just a beginning.
+
+-   24 Jul 2015 Hacking a radio in a car:  
+    *"… the computer systems built into Fiat Chrysler cars: the flaw can
+    be exploited by an attacker to wirelessly take control of the
+    engine, brakes and entertainment system ..."  
+    "… the US National Highway Traffic Safety Administration has
+    recalled 1.4 million of the manufacturer's cars after a dangerous
+    software flaw was revealed just days ago..."*  
+    <http://www.theregister.co.uk/2015/07/24/chrysler_recall_for_wireless_hacking_hole/>
+-   One day (likely not that far) we could see car blocked by
+    ramsomware, or cyber terrorism using cars as weapon if nothing is
+    done.  
+
+As malicious hackers or terrorists are smart and well organised, we know
+that if we let them enter a system, even by a side door, they will work
+they way to the more juicy part of the system to monetise their work.
+
+As connected cars are going to interact with our phone and the cloud,
+they will become a vector of attack not very dissimilar to the video
+surveillance cameras in recent cyber attack with the added complexity
+that tracking a mobile source will be more complex.
+
+ http://www.theregister.co.uk/2016/10/10/iot\_botnet/
+
+## Scope 
+Designing Connected cars without enabling a high level of security is
+not acceptable and will be soon a key market requirement for any
+respectable automotive company.
+AGL is aimaing at providing a reasonable level of security by default.
+The level of default security will evolve with the time and future releases to align with market expectations and needs.
+
+In order to converge on such an open question, we need to take
+assumptions which are realistic for the targeted domain, in our case a
+Connected Car.
+
+The assumptions selected are the following:
+
+-   Secure boot with Hardware chain of trust.
+-   recent LTSI based kernel (4.1.x, 4.9.x, ...)
+-   kernel and middleware securely updated once in a while  
+    in the future that rate will increase a lot.
+-   Middleware and Application compiled with up-to-date compiler
+    protections activated and checked through a static analysis process.
+-   Rootfs (/) in read-only, /home encrypted., integrity protected by
+    IMA/EVM
+-   Customisation reduced to Apps vetted by the manufacturer's store
+-   24/7 connection to the outside world (sensor and internet).
+-   Developer mode not active by default.
+-   There is no administrator (only a user) for the product which mostly
+    run non attended.
+
+We can see that in such configuration, the base OS (kernel&middleware)
+represents a well guarded entry point for a malicious hacker. The
+combination of trusted boot, integrity enforcement and rootfs in ro,
+creates a set a garded walls to anyone, who would try to modify valid
+code on the product.
+
+The main risks will lie in the exploitation of Zero Days security holes
+in the base OS (by definition correction and update is always an after
+the fact event in that case) and the Apps store where vetting process
+cannot afford to be that solid if real flexibility is required.
+
+We cannot completely avoid external activation of the base OS security
+holes (publicly known or not) but we can limit the actions and reach of
+any compromised code.
+
+We will start by reducing the surface of attack by designing a product
+without open backdoors (e.g. cars drivers do not need a ssh connection
+nor tcpdump, so why to install the such development code on the image,
+and continue by reducing the capabilities which can be claimed by any
+code to the minimum required. This can be done by running the code with
+a non administrator’s user ID (non root) and by removing the unrequired
+capabilities and file access at code launch via Mandatory Access Control
+(MAC) and the Posix Capabilities.  
+In the case of Smack, the general concept is to associate different
+label to specific code. As the MAC label cannot be changed by the
+process itself, it enables the security rules set to enforce the respect
+of the predefine code behaviour. Code with connects to the outside world
+by any mean, should first benefit of these special security
+configurations. The default policy should be good enough cover the
+security needs of most non connecting code.
+
+Once the surface of attack is reduced, you need to reduce possible
+damage when a malicious user will have found his way in. *Please
+remember that in security the question is not to know if someone will
+break in, but rather when, how you will detect it, and how to limit
+potential damages.*
+
+In this phase we will take care to limit options for a malicious user to
+move sideways and activate code that would help him to get more control
+over the system. We will pay a detailed attention to any code which can
+grant more privileges, change MAC label, create new user, install new
+Apps or update. Those types of code are normally called from a very
+limited entry points in the system and once again the MAC system is your
+best friend when it comes to restrict activation from valid vector.
 
-## Scope
 
 ## Glossary
 
+DAC Discretionaly Access Control
+MAC Mandatory Access Control
+SoC System on Chip
+
+