[GENIVI security group] Security group assessment method discussion

Stacy Janes stacy.janes at irdeto.com
Fri Aug 12 14:26:12 EDT 2016


The calls are typically 7am CET.


From: Jeremiah Foster <jeremiah.foster at pelagicore.com>
Date: Wednesday, August 10, 2016 at 9:26 PM
To: "Gunnar Andersson ()" <gunnar.x.andersson at volvocars.com>
Cc: "tal.bendavid at karambasecurity.com" <tal.bendavid at karambasecurity.com>, "peter_yang at trend.com.tw" <peter_yang at trend.com.tw>, Yoram Berholtz <yoram at argus-sec.com>, "anuja at computer.org" <anuja at computer.org>, "genivi-projects at lists.genivi.org" <genivi-projects at lists.genivi.org>, "assaf.harel at karambasecurity.com" <assaf.harel at karambasecurity.com>, Antonio De Rosa <Antonio.DeRosa at opensynergy.com>, Stacy Janes <stacy.janes at irdeto.com>
Subject: Re: [GENIVI security group] Security group assessment method discussion

So it's the 18th of August? At what time?

On Aug 10, 2016 8:00 PM, "Andersson, Gunnar" <gunnar.x.andersson at volvocars.com<mailto:gunnar.x.andersson at volvocars.com>> wrote:
Bi-weekly. Got it. Going back to sleep.

Sent from phone - please excuse brevity.

On Aug 11, 2016, at 01:45, Stacy Janes <stacy.janes at irdeto.com<mailto:stacy.janes at irdeto.com>> wrote:

It should be in one week + 6 hours from now :-}  The last call was on Aug 4.


From: "Andersson, Gunnar" <gunnar.x.andersson at volvocars.com<mailto:gunnar.x.andersson at volvocars.com>>
Date: Wednesday, August 10, 2016 at 7:09 PM
To: Stacy Janes <stacy.janes at irdeto.com<mailto:stacy.janes at irdeto.com>>
Cc: "anuja at computer.org<mailto:anuja at computer.org>" <anuja at computer.org<mailto:anuja at computer.org>>, "tal.bendavid at karambasecurity.com<mailto:tal.bendavid at karambasecurity.com>" <tal.bendavid at karambasecurity.com<mailto:tal.bendavid at karambasecurity.com>>, "genivi-projects at lists.genivi.org<mailto:genivi-projects at lists.genivi.org>" <genivi-projects at lists.genivi.org<mailto:genivi-projects at lists.genivi.org>>, "peter_yang at trend.com.tw<mailto:peter_yang at trend.com.tw>" <peter_yang at trend.com.tw<mailto:peter_yang at trend.com.tw>>, Yoram Berholtz <yoram at argus-sec.com<mailto:yoram at argus-sec.com>>, "assaf.harel at karambasecurity.com<mailto:assaf.harel at karambasecurity.com>" <assaf.harel at karambasecurity.com<mailto:assaf.harel at karambasecurity.com>>, Antonio De Rosa <Antonio.DeRosa at opensynergy.com<mailto:Antonio.DeRosa at opensynergy.com>>, "Feuer, Magnus" <mfeuer1 at jaguarlandrover.com<mailto:mfeuer1 at jaguarlandrover.com>>
Subject: Re: [GENIVI security group] Security group assessment method discussion

Sorry for an unrelated topic but I did not find any WebEx scheduled tomorrow and I have been searching for an email with the customary "Next meeting time" and/or a wiki page with minutes.

Is there a security meeting planned at the usual time (in 6 hours from now)? Apologies if I missed some correspondence or did not know where to look.

- Gunnar
Sent from phone - please excuse brevity.

On Aug 4, 2016, at 00:53, Feuer, Magnus <mfeuer1 at jaguarlandrover.com<mailto:mfeuer1 at jaguarlandrover.com>> wrote:
Hello Stacy, and welcome to GENIVI.

Since we at the RVI expert group are in the middle of putting together a PKI system to be used on top of our existing (TLS-based) security, I think we would be a good first candidate to run through the process

Ulf Wiger is formally responsible for the effort, although we are doing this as a team of about 5-6 people.

Since we are still in the design phase of PKI, we don't really have any documentation yet. Would it, as a starter, be possible to bring you in on a conf call where we walk you through the current state of our ideas?


/Magnus F.

Head System Architect - Open Source Projects
Jaguar Land Rover

Email: mfeuer1 at jaguarlandrover.com<mailto:mfeuer1 at jaguarlandrover.com>
Mobile: +1 949 294 7871<tel:%2B1%20949%20294%207871>

Jaguar Land Rover North America, LLC
1419 NW 14th Ave, Portland, OR 97209
Business Details:
Jaguar Land Rover Limited
Registered Office: Abbey Road, Whitley, Coventry CV3 4LF
Registered in England No: 1672070

This e-mail and any attachments contain confidential information for a specific individual and purpose.  The information is private and privileged and intended solely for the use of the individual to whom it is addressed.  If you are not the intended recipient, please e-mail us immediately.  We apologise for any inconvenience caused but you are hereby notified that any disclosure, copying or distribution or the taking of any action in reliance on the information contained herein is strictly prohibited.

This e-mail does not constitute an order for goods or services unless accompanied by an official purchase order.

On Sun, Jul 31, 2016 at 8:58 AM, Stacy Janes <stacy.janes at irdeto.com<mailto:stacy.janes at irdeto.com>> wrote:
Hello all,

I would like to start the conversation on the methods the Security Team will use to construct a security analysis for projects by other GENIVI Expert Groups.  Below is a recommendation of the basic framework based on work I have done in the past.  All aspects are open to debate as I want to ensure we get to the best solution possible.  I suspect the process will be continuously fine tuned as we move forward.

1. At the beginning of a new engagement with an Expert Group, the team members that will be involved in that assessment should read and understand the Architecture/Design from the EG as it exists.  The team will need to be in constant contact with Architect and other technical experts from the EG (calls, email, etc) during this phase.

2. During this phase, the team to strive to acquire a detailed understanding of the following:
       a. What assets does the architecture already have listed?
       b. What data is stored by the system?
       c. How is data handled by the system (in transit, in process, at rest)?
       d. What interfaces does the system present to external systems?
       e. What interfaces does the system utilize from external systems?
       f. What existing security mitigations have already been built into the system (secure storage, cryptographic keys, security functions)?

3. From the above, the security team will be able to gather the first round of assets and document them.

4. The security team documents their understanding of the architecture/design, including the assets that are known at this point.  For each asset, the document should include a description of the asset, their importance and the result of them being compromised.  This is then presented back to the client EG for review to ensure everyone has a common understanding of the system.

5. The next step is to go through the process of discovering the attack vectors that would be viable against the system.  For this part of the process, I prefer to use Attack Trees (https://www.schneier.com/academic/archives/1999/12/attack_trees.html).  These are not only good for the assessor to work out all of the possible attack vectors, but we have found them to be very useful for non-security people to understand how we get to certain attack vectors.  Attack Trees will also help the team divide up the analysis work, as the different sub-trees can be handled by individual team members.

6. The detailed analysis through attack trees will expose more assets that will need to be documented similar to the original list.

7. For each attack vector, we use a STRIDE (see below) description and document the difficultly and result of an exploit of that vector.  The HEAVENS Security Model has a good approach for using STRIDE to document automotive risk assessments and I think we can borrow from that.  There is a short overview of HEAVENS in Appendix A.1.5 of J3061.

8. Typically, in a commercial evaluation, the final document will contain suggested mitigations for all of the attack vectors exposed by the attack trees.  In the case of GENIVI however, I recommend the following:
       a. Suggest mitigations in the form of architectural or design changes if appropriate
       b. Suggest open-source mitigations (list benefits and limitations) if appropriate
       c. Reference or create a specific security requirement (from our that can be used to determine commercial mitigations in the final product.

9. Mitigations and architectural/design changes can introduce new assets.  These and the threats to them need to be documented as above.

10. Any new requirements generated as part of ‘c’ will be integrated into the existing security requirements document if appropriate.

Before we engage on the first assessment, those of us with experience doing this type of work can present the various aspects (how to determine a security asset, how to create an attack tree) to the team.  From there, I think we could start on a small project to work out the kinks and figure out what needs to be changed.

Also, in the last call, we discussed implementing “Compliance and Robustness” rules as a way to document our security requirements where all of the requirements are listed in the “robustness rules” and the “compliance rules” map specific types of features to specific requirements.  If we are in agreement on this, we should start with the existing security requirements list and see how they logically break up.

Description of STRIDE:
• Spoofing identity: An example of identity spoofing is illegally accessing and then using another user's authentication information, such as username and password.
• Tampering with data: Data tampering involves the malicious modification of data. Examples include unauthorized changes made to persistent data, such as that held in a database, and the alteration of data as it flows between two computers over an open network, such as the Internet.
• Repudiation: Repudiation threats are associated with users who deny performing an action without other parties having any way to prove otherwise—for example, a user performs an illegal operation in a system that lacks the ability to trace the prohibited operations. Nonrepudiation refers to the ability of a system to counter repudiation threats. For example, a user who purchases an item might have to sign for the item upon receipt. The vendor can then use the signed receipt as evidence that the user did receive the package.
• Information disclosure: Information disclosure threats involve the exposure of information to individuals who are not supposed to have access to it—for example, the ability of users to read a file that they were not granted access to, or the ability of an intruder to read data in transit between two computers.
• Denial of service: Denial of service (DoS) attacks deny service to valid users—for example, by making a Web server temporarily unavailable or unusable. You must protect against certain types of DoS threats simply to improve system availability and reliability.
• Elevation of privilege: In this type of threat, an unprivileged user gains privileged access and thereby has sufficient access to compromise or destroy the entire system. Elevation of privilege threats include those situations in which an attacker has effectively penetrated all system defenses and become part of the trusted system itself, a dangerous situation indeed.

Discuss :-}

Stacy Janes
Security Group

genivi-projects mailing list
genivi-projects at lists.genivi.org<mailto:genivi-projects at lists.genivi.org>

genivi-projects mailing list
genivi-projects at lists.genivi.org<mailto:genivi-projects at lists.genivi.org>

genivi-projects mailing list
genivi-projects at lists.genivi.org<mailto:genivi-projects at lists.genivi.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genivi.org/pipermail/genivi-projects_lists.genivi.org/attachments/20160812/ec27dfd9/attachment.html>

More information about the genivi-projects mailing list