diff options
| -rw-r--r-- | sec-blueprint/01-overview.md | 133 | ||||
| -rw-r--r-- | sec-blueprint/02-plateform-security.md | 81 | ||||
| -rw-r--r-- | sec-blueprint/03-security-concepts.md | 423 |
3 files changed, 630 insertions, 7 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 + + diff --git a/sec-blueprint/02-plateform-security.md b/sec-blueprint/02-plateform-security.md index ae29818..dc6e0ab 100644 --- a/sec-blueprint/02-plateform-security.md +++ b/sec-blueprint/02-plateform-security.md @@ -14,20 +14,93 @@ layout: techdoc {:toc} ## Platform Definition +The platform includes a set of HW supporting an AGL Linux distribution and AGL compliant Application and Services. +On the HW side this will include : + - a SoC + - RAM, ROM and Storage + - Peripherial +The AGL SW platform includes all the SW required after the initial boot loader in order to support AGL compliant applications and services : + - Linux BPS configured for the reference boards + - Set of drivers for the common peripherials available on the reference boards (they may not all be Open Source) + - Application Framework + - Windows/layer management to allow Application to gracefully share the displays + - Sound resource manager to allow Application to gracefully share the displays + - an atomic update system support / as read only and MAC (Smack) + - set of building and debug tools (based on yocto project) ## Secure boot +The secure boot is tighly linked to the SoC and will vary from SoC to SoC. +AGL does not provide the secure boot but AGL platform is designed to be able to operate with a secure boot. ## Certificate and Key Management +The default Key management provided by AGL is SoC independant and use leyrings. Thismodel is less secured than a SoC HW integrated model and we advise AGL adopters to activate HW support from their selected SoC as much as possible. +The activation of HW support for Key management if left to the integrator. -## Resource Management +## Madatory Access Control configuration +The general Smack schema used by AGL is inspired from Tizen 3 Q2/2015 +but tries to enable a better protection of code ran via run time (e.g. +JavaScript, Python) and enable Cloud/Device hybrid applications model. + +It takes into account the Tizen2 experience of creating too complex MAC +rules and limit the use of MAC for process file access tracking leaving +the application capabilities management to other model (Cynara and the +Security manager). + + +https://wiki.tizen.org/wiki/Security/Overview\#Implementation\_in\_Tizen\_3.0\_2015.Q2 + +*You will notice that the Smack initial configuration described bellow, +even if not obvious to read, represents a manageable complexity which +should be understood in no more than a few hours.*** +** + +This initial Smack schema tries to clearly keep the differentiation +between the execution Smack label of a Process and the Smack label of a +file. The first one defines which file a process can access and how +files will be created by the process. The second defines which process +can access the file. By default a process will execute with its file +access Smack label but that can be overwritten by an execution Smack +label. + +The system is split in 3 domains : ***(to be updated with latest model)*** -## Trust Zone +- **Floor**, which includes the base services and associated data and + libraries of the OS which are unchanged during the execution of + the OS. +- **System**; which includes the basic services of the OS and the data + that they maintain. Those data are expected to change during the + execution of the OS. +- **User**, which includes code providing services to the user and + their associated data. + +**Note: ** Smack label names must be less 254 Char long. In order to be +able to use Smack label on Netlabel CISCO (IPv4) a schema creating label +of less than 23 Char will be required. + +So please note that the name given in this table are for clarification +kept in their long form, but are likely going to be shorten in a real +implementation. + +***WIP table of smack label required*** + +## Secured transport for Binder implementation + +## Resource Management -## Platform Software Update +## Trust Zone and Trusted Execution +Trusted zone and Trusted execution are services provided by the SoC vendors and services offered can varie even within the same familly of SoC depending of their configuration. +AGL platform does not provide any Trusted Zone or Tusted Execution direct support as these are specific to each indivual SoC but on the other side the AGL platform is architectured to ease the use of HW helpers. +In particular AGL advise whenever possible to take profit of HW helpers available to store critical data in the secure zone and to execute critical validatin code (in particular signature check) in trusted execution mode. ## Critical Resource Protection -## Update +## AGL Platform Software Update +AGL platform provides by default a software update module which is capable to respect the AHL platform update requirements: + - support Smack as MAC + - support read only / file system + - support integrity enforcement such as IMA and EVM. + - +Any update software respecting these requirement can be used. AGL advise strongly to only use solutions that enable a strong verification of the validity and integrity of the download update or upgrade what ever is the selected solution. ## cloud service infrastructure diff --git a/sec-blueprint/03-security-concepts.md b/sec-blueprint/03-security-concepts.md index af50a8c..114bc8b 100644 --- a/sec-blueprint/03-security-concepts.md +++ b/sec-blueprint/03-security-concepts.md @@ -14,12 +14,433 @@ layout: techdoc {:toc} ## Security Principles +When connecting a car to the internet, not only we create a mobile entry +point to our private life, we also relocate our entry doors anywhere in +the world. Neither all places on this planet are nice nor safe, nor are +the people. The locks and alarms on cars, will give only a fake +impression of security once that internet connection has entered the +place. -## Access Control +Internet enables the worse of human side to get access to private +domains. If we are not careful, it will likely be invaded in a very +short time following connection.. + +**So, connected cars security must be designed as a military vehicle +which would be deployed in a high risk zone even when designing cars for +out towns and villages**: + +- Physical access to the car should not be a white card to hack + the system. Most cars sleep in the streets and public car parks where physical + accessibility is easy. +- Known defect should be corrected by SW update in real time, without a return to + home or garage. +- A separation of functionalities in isolated domains should allow the + car to remain safe and operational by limiting the contamination, + would a malicious SW succeed to pass the protections. +- Connectivity between the various domains should be restricted to the + minimal set required for their operation. +- Software loaded in cars and in the cloud should be vetted in + accordance with its capability to access critical resources. The + vetting authority must be controllable, enforceable and revocable. +- Inside each domain, sub domains should be created to limit even + more, the nuisances capabilities of a successful malicious code. +- Software or devices not wetted should never be able to access any + critical resources. + +**The strategy can be summarise as “anything, which is not explicitly +authorise is strictly forbidden”,also known as ‘white listing’ policy.** + +We all understand those concepts, and nevertheless reports still show +that very little people care about implementing protection against those +risks yet. As a consequence most Connected Car projects are coming on +the market with major security holes. It will take some time *(and +likely some catastrophes)* for the Automotive Industry to clean up the +pre-cyber security awareness designed products. + +The complexity induced by a security framework requires serious effort +on the design side and complexifies the code execution. Fortunately our +modern CPUs, which are very fast and ernergy efficient, can reduce this overhead +to very acceptable extra work load on the computing and energy +sub-systems. + +The challenge of Connected Cars is very similar to embedded devices +in general. Within AGL we are defining solutions, which can enable this +new market to emerge without requiring each product design to be +chaperoned by security experts. *The world does not hold enough security +experts to even overview even a few percent of the projects that are required +to create all connected devices that will be launched in the next 10 +years.* + +If embedded developers must implement complex security models +without, having neither the time nor the skills, to architecture them +correctly, *they can only succeed by reusing ready made trusted +solutions*. Fortunately Connected Cars are based on some flavour of +Linux operating system which has, due to its long serving years in many +critical domains, a large offering of security options. + +AGL only focus on the security facilities offered under +Linux operating system for the connected car market. +Non Linux Operating systems which can also be present in a connected car, are not covered by AGL platform security model. + +## Strategy +There is no miracle solution. When deciding which security strategy, you +will need, first to try to evaluate all the possible attack vectors, +then to define your priorities and your limits. + +Even if today complexity is mostly in the software (SW), we still need +some hardware (HW) to run it. Securing the HW is a very complex task +which fortunately is likely yet not required for Connected Cars. I will +not open more the topic here. Nevertheless applying a healthy design +attitude by reducing obvious direct risk vectors (debug serial connector +wired in production, tracks with clear communication channel easy +accessible on PCB, …) should be done. + +Would your automotive project requires a more protected HW, you will +find plenty of literature on that topic. I personally like this +relatively old (2004) paper from J Grand as an introduction to the +domain. +http://www.grandideastudio.com/wp-content/uploads/secure\_embed\_paper.pdf + +On the SW side, the most efficient model is to work by layer : + +- **be sure that the desired SW is loaded** + On non connected devices, a trusted boot is considered a valid + enough solution, but Connected Cars requirement to enable + applications be added after the initial equipment provisioning, + requires more than a simple trusted boot. + A strategy to control the integrity of the software and its + configuration is required. +- Be able to change (upgrade) the software to correct a newly + discovered risk. + Assuming that the system will never be broken is an utopia. The + right strategy is to plan how to recover from the discovering of a + new security issue to avoid its propagation. + *This upgrade mechanism must be particularly solid has it has to be + capable of being executed on a compromised system without the + support of a skilled operator.* +- **Only select trusted Linux drivers.** + In Linux, drivers are executed with the same privilege level than + the Kernel itself. I short a malicious or hacked driver is an + uncontrolled open door to the hart of the system. Only vetted driver + should be used and any complexity unique to the platform should be + pushed in the user space domain. This remark is particularly + important when introducing drivers that are connecting with the + outside world. + Ideally dynamic driver integration after boot should be banned even + if that would limit the flexibility of hot plug for USB devices. + Solutions to reinforce the Linux Kernel integrity during execution, + can be activated but they are an order of magnitude more complex to + activate than keeping bespoke logic in user space. + https://www.isoc.org/isoc/conferences/ndss/11/pdf/3\_1.pdf +- **Isolate the core of the system from the middleware.** + By default the protection on Unix type systems (and so Linux) is + done by allocating the user a set of access rights. The side effect + is that any code running under a given name can access all the + resources that is given to that user. Furthermore it is possible at + any time to further expend this access to other users. *As most of + code in traditional embedded software run with the Administrator + privilege (root) we foresee the danger of this traditional + embedded model. Fortunately Linux provides a Security model + called LSM.* ( + https://en.wikipedia.org/wiki/Linux\_Security\_Modules) + It allows to create an access strategy which is not controlled by + the user but rather by the system configuration. Multiple front end + are available to control LSM and that will be studied a bit later in + this paper. This allows to create a Mandatory Access Control (MAC) + which is a powerful tools to avoid compromised code to gain access + to extra resources to propagate further. + Other restriction based on the c-groups, the Posix capabilities and + the Seccomp can used in addition to LSM to further mitigate + the risks. +- **Isolate Applications** + IoS and Android phones have initiated the Apps model and nowadays + launching a product which cannot be extended by Apps (from a closed + or open Store) after the creation of the device is a risky + marketing strategy. While the model of Apps loaded from an open + store is reserved to a very small category of mass consumer devices, + the capability to load Apps after the creation of the initial SW is + a very attractive way to reduce the time to market as well as the + reaction time to changing market demand. + In particular it would allow car manufacturers, to customise the car + SW, individually on the production line, to the buyer wish. + *By design Apps are created with a quite loose coupling with the + core SW. The default Linux DAC (Discretionary Access Model) is not + the most reliable for limiting the access to the system capabilities + to the minimum required.* + Associating the validation of the origin of an App to the resource + that such App can claim access, with the enforcement of restriction + in accessing the system resources to those explicitly granted, is a + far more reliable approach. +- **Private data protection** + *Cars know a lot about us, from where we go, to who we call, who get + in our car (via the phone detection) and hold data that we are not + willing to let go in the Open without our explicit consent.* + This creates three main families of requirements : + + - Requires a safe provisioning of new devices and App in the + system (know who is who and who does what. ) + - Enforce encryption to any traffic going out. + - Enforce encryption on local storage for personal data to + mitigate off line attack risk. + - Enforce isolation of devices own by multiple users that connect + to the car. ## Secure Boot +The trusted or secured boot is a facility offered by most Systems on Chip (SoC) +which enforces : + +- booting the system in a known state + (e.g. all the RAM set to "0", all internal peripherals set + to silent) +- providing a validation that the loaded initial code is signed by a + valid authority + (in short the SW is really coming from a known valid source). + +As the feature is very closed to the HW, almost as many solutions exist +than SoC vendors and many of them requires to buy a large volume of SoC +in order to get access to the facility and are by that requirement not available to generic platform developers. + +The Secured Boot option associated to a modern boot loader such as UEFI or uboot +allows to restrict the execution of the system initialisation code to those which which carries a valid signature. +Even if the system presents some weaknesses and constrains, it is likely +*a valid and accessible solution for most device manufacturers even for +medium volume.* + +Once the trusted boot activated, you will have a good confidence +*(history shows that security loop holes are always available +somewhere)* that the code which will start to run when powering the +device, is the expected one. + +## Read Only root file system. + +In most embedded system the core OS is under control of the device +manufacturer. *A very simple and efficient way to limit opportunities to +get the core OS and middle-ware to be modified by a malicious code, is +to store it on a read only partition*. Even if that is not 100% +bulletproof it seriously complexifies the level of required knowledge to +break into the OS and greatly eases, the implementation of a recovery +strategy. + +In order to enable some local persistent changes such as those required +to register some network or locale configurations, an overlay can be +created for some directories. Since Linux 4.0, the kernel supports by +default OverlayFS which provides that facility and support the extended +file attributes required by file base MAC such as SELinux and Smack. +https://github.com/torvalds/linux/commit/e9be9d5e76e34872f0c37d72e25bc27fe9e2c54c + +## Code Integrity during execution + +In the embedded world it is quite acceptable to restrict the end user to +operate the system as designed. We can take profit of this favorable +position, to limit the capabilities of a malicious applications to +change our Operating System (OS) after the protected initialisation +(trusted boot). This can be done *by activating an integrity enforcement +such as IMA/EVM on all the core OS.* +http://sourceforge.net/p/linux-ima/wiki/Home/ + +In short IMA allows the kernel to check that a file has not been changed +by validating it against a stored/calculate hash (called label) while +EVM checks the file attributes (including the extended ones). + +Two types of labels are available : + +- immutable and signed +- simple + +The signed labels are reserved for code or data which are static and +provide the best level of protection. The signing tool remains external +of the device. The simple hashes are reserved for code which can be +install dynamically and the hash can be recalculated on the fly by the +OS providing a lesser level of protection. + +Obviously some restriction will be imposed on which SW modules are +allowed to update an IMA/EVM label and all public keys used for +signature checking must be protected with an unmutable label or stored +in the HW security sub-system. + +## Update and Ugrade + +The integrity enforcement does not allow immutable files to be updated +on line. The Integrity system would detect the violation and block any +further reading of such file. + +*The update solution must cater with this constrain and must be +implemented via an atomic model where all changes are done in one step, +on the entire core OS, generally just before a reboot..* + +## Mandatory Access Control (MAC) + +Connected Cars are comparable to middle volume consumer managed products +(very similar to connected TV), by this, I mean, product where the +software is entirely provided by the device manufacturer. The main side +effects are well known : + +- low cost and small CPU +- high control of the OS and Middleware loaded on the box +- user, at best, very slow to activate update +- no visibility by the manufacturer of the external environment where + the device is connected. +- No skilled administrator +- No recovery console. + +For those reasons, a solution like Smack has been selected by AGL as the +best suited LSM front end. Furthermore, its adoption on Tizen by Samsung +for delivering millions of Smart TVs enable an active community focussed +on keeping good performance on smaller CPUs. +<https://wiki.tizen.org/wiki/Category:Security> ## Applications +*Apps are the weak security vector in many modern system.* Car +manufacturers need to add bespoke/localised App developers in order to +make their product commercially attractive. It is a fast moving world +very different to the use and habits of the Automotive industry. + +Defining the right level of App vetting is a real challenge. A quick +reality check on markets where Apps exist, such as Mobile, Smart TV or +Smart Watches, show that the detection of roke Apps is very complex +already on platforms that impose the execution via a Virtual Machine, so +we can imagine what is the complexity, when native code support is +required in order to run on very small CPU. + +**As we cannot fully trust Apps, we have to contain them**. This can be +done by : + +- Limiting Apps download origin to trusted ones. +- Restrict Apps privileges, resources and APIs access to what is + explicitly authorised +- Isolate Apps runtime + +Restricting Apps origin to trusted source is quite simple. The simple +use of a certificate to validate the App signature is a powerful model +when associated with an installer code which cannot be called via a back +door. A simple model consists in separating the download process and +exposed (UX, connected) from the installer code which can validate the +App origin and installation in a isolated process with a lower surface +of attack. + +Restricting Apps privileges requires first to know what are the +requested and authorised privileges. The granularity of these +privileges, must offer a good flexibility while remains simple, to be +understood by the developers and the user. The compromise will depend of +the target audience. The current return of experience from Android and +Tizen, tend to reduce the list of privileges to a shorter list rather +than in opposite. The creation of goup or App class is an other valid +model. + +The list of requested privileges will be associated to the App in a +Manifest. A practical extra validation of the requested privileges can +be done depending of the App origin and signature level (e.g. +Manufacturer, Partner and Community stores). + +The association between the App and its privileges list must be kept +safe and available for enforcement in the system. The Samsung originated +Open Source project Cynera (https://github.com/Samsung/cynara) provides +such service and is optimised for execution on small SoC. + +Isolating the App when running is the most challenging task, it requires +to let the App access enough of the system to execute its task but no +more, to mitigate any malicious activity. One model to address this +challenge consist in slicing the access to the system : + +- CPU, RAM +- devices +- network +- middleware +- files +- libraries and system calls. + +CPU and RAM over use can be restricted with a correct C-Group +configuration. + +Devices and files can be isolated by MAC and DAC. + +Network access can be controlled via MAC in association with the +nftables. + +Middleware in AGL is access via binders which provides not only an +isolation via creation of different security context but adds the +concept of authentication which limit attack through man-in-the-middle +*https://en.wikipedia.org/wiki/Man-in-the-middle\_attack*. + +The control of Libraries and system API usage is far more complex. MAC +advanced usages can help in this domain but Seccomp-BPF can go further. +Seccomp which is an upstream feature of the Linux kernel is used by +Mozilla and Chrome in their browsers and enable a low level protection +solution. Seccomp can quickly induce a performance hit and access rules +must remain simple. +The following page provides interserting reports on performance cost of +that feature. (https://wiki.tizen.org/wiki/Security:Seccomp) for one +system. + +###Name spaces + +Containers have made Linux name spaces visible to the mass. They are +very popular and unfortunately often confused with security enforcement +due to their common use as light virtualisation solution in the cloud. + +Whichever model of container is referenced, they all use the Linux +various name spaces +(http://man7.org/linux/man-pages/man7/namespaces.7.html). The general +idea is to share a common kernel and to let each containers run its own +virtual Linux user space and middleware. With the increased CPU +performance and the facility provided by novel filesystem architectures +such as overlayfs, the files and code which happen to be unchanged +between different containers can even remain shared transparently on +disk and in RAM, enabling the use of containers for single App in the +cloud or on small embedded system. + +From a security point of view, while containers provides an isolation +between themselves, it must remain present to the designer that : + +- kernel is shared and security weaknesses and zero day defects can be + used to cross domains. +- As each container can provides its own version of the middleware, + upgrading the system is not enough to correct known security issues. + Each container must individually be updated. +- Due to the transparent overlay model sharing files between + containers, predicting the actually used disk space is challenging. +- UX needs to share the same Display and Input what can open back + doors in the system. + +At least two lines of interest seem to provide a serious value for the +Automotive domain : + +- Isolating subsystem +- Easing development + +The isolation model is very interesting when multiple service providers +needs to share the same embedded device. A commonly listed use case, is +the sharing of an IVI system with games or cloud multimedia services. + +The ease of development, is potentially even more valuable. One of the +challenge faced by the embedded SW industry is the lack of skilled +embedded software developers. *Enabling web and traditional IT +programmers to work in a known environment and to run their App on an +IoT device without requiring to become an embedded SW expert would be of +a high value*. + +The Smack provides a solution to create MAC name spaces, so in theory +nothing would stop to launch containers for each Apps in an isolated +environment. + +As further reading on similar topic, you can have a look at the Open +Source Vasum project. +https://github.com/Samsung/vasum +https://wiki.tizen.org/wiki/Security:Vasum ## Process Management +While developers will always have a good reason for delaying the +activation of the security layers, to succeed, you will need to keep a +few base concepts enforced: + +- Security is invasive. It goes everywhere. +- Security cannot be apply as a patch at the end of the project. +- System must be developed with the security 'on' or it will + never work. +- SW must be written secured first time, as late adaptation is + too difficult. +*Underestimating the resistance of the developer team is a common +mistake which can lead to massive over costs and delays. *Implication of +the right expert and management drive from the beginning is a +requirement that cannot be negotiated. |