EP3151114A1 - Système de développement de logiciels dans un développement de systèmes basé sur une méthode basée sur un modèle - Google Patents

Système de développement de logiciels dans un développement de systèmes basé sur une méthode basée sur un modèle Download PDF

Info

Publication number
EP3151114A1
EP3151114A1 EP16189414.2A EP16189414A EP3151114A1 EP 3151114 A1 EP3151114 A1 EP 3151114A1 EP 16189414 A EP16189414 A EP 16189414A EP 3151114 A1 EP3151114 A1 EP 3151114A1
Authority
EP
European Patent Office
Prior art keywords
control model
threat
data
development system
elements
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP16189414.2A
Other languages
German (de)
English (en)
Inventor
Nobukazu Kurauchi
Toshihisa Abe
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Management Co Ltd
Original Assignee
Panasonic Intellectual Property Management Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from JP2016113938A external-priority patent/JP2017068825A/ja
Application filed by Panasonic Intellectual Property Management Co Ltd filed Critical Panasonic Intellectual Property Management Co Ltd
Publication of EP3151114A1 publication Critical patent/EP3151114A1/fr
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/35—Creation or generation of source code model driven
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033—Test or assess software
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0209—Architectural arrangements, e.g. perimeter networks or demilitarized zones
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/107—Network architectures or network communication protocols for network security for controlling access to devices or network resources wherein the security policies are location-dependent, e.g. entities privileges depend on current location or allowing specific operations only from locally connected terminals

Definitions

  • the present disclosure relates to a software development system and a computer-readable non-transitory recording medium having a program recorded thereon, in system development that is based on the model-based method.
  • model-based development System development that is based on the model-based method (hereinafter, referred to as model-based development) is a known method for system development (for example, Japanese Unexamined Patent Application Publication No. 2004-280786 ).
  • model-based development an executable control model is created from specifications such as design information.
  • the validity of specifications such as design information can be verified by performing a simulation on the basis of a created control model.
  • the techniques disclosed here feature a software development system provided with: a threat database which retains data indicating one or more threats that are factors that cause risks in information security to occur; and circuitry which, in operation, with regard to individual elements of a control model which is created from design information for a development target by a development system handling executable models and is an executable model in which the development target is simulated, extracts data of corresponding threats from the threat database to thereby create and output data for a threat list that indicates a plurality of threats for the control model.
  • these general or specific aspects may be realized by a method, an integrated circuit, a computer program, or a recording medium such as a computer-readable CD-ROM, and may be realized by an arbitrary combination of a system, method, an integrated circuit, a computer program, and a recording medium.
  • an assessment device disclosed in Japanese Unexamined Patent Application Publication No. 2015-41167 automatically calculates a risk value for a threat by defining the data necessary for risk assessment in accordance with an input instruction of a tool on the basis of information that can be objectively input such as design specifications.
  • threat assessment and model-based development are conducted independently from each other. Therefore, even when a threat assessment (threat analysis) is carried out at an upstream stage of system development and reflected in the system design, assuring that a security countermeasure operates correctly depends on a vulnerability assessment at a downstream stage.
  • Fig. 31 is a diagram depicting a system development procedure according to a V-shaped model.
  • a vulnerability assessment is generally carried out at the system testing stage, which is closer to being an actual product.
  • a vulnerability is discovered in a vulnerability assessment or in the case where an unexpected new threat is found after system testing, it is necessary to once again carry out a threat analysis, and repeat the procedure from system design to system testing. That is, in the case where a vulnerability is found in a downstream stage, it is necessary to provide feedback to upstream stages and design/implementation and to repeat the procedure, and therefore considerable refactoring occurs in the development work, and as a result, there is a problem in that development efficiency cannot be improved.
  • cases may arise where a complete countermeasure cannot be implemented with respect to a newly found threat and a product is dispatched with the countermeasure remaining incomplete.
  • the present inventor provides a software development system and the like with which it is possible to improve development efficiency in system development that is based on the model-based method.
  • a software development system is provided with: a threat database which retains data indicating one or more threats that are factors that cause risks in information security to occur; and circuitry which, in operation, with regard to individual elements of a control model which is created from design information for a development target by a development system handling executable models and is an executable model in which the development target is simulated, extracts data of corresponding threats from the threat database to thereby create and output data for a threat list that indicates a plurality of threats for the control model.
  • the development system handling executable models is a model-based development system.
  • the circuitry may be provided with a countermeasure database that retains data of countermeasure means for each of the one or more threats, extract the countermeasure means for each of the plurality of threats included in the data for the threat list from the countermeasure database to thereby create and output data for a countermeasure list indicating a list of the countermeasure means for the control model, and output the data for the countermeasure list to the development system handling executable models to thereby cause the development system handling executable models to reflect the countermeasure list in the control model.
  • a countermeasure database that retains data of countermeasure means for each of the one or more threats, extract the countermeasure means for each of the plurality of threats included in the data for the threat list from the countermeasure database to thereby create and output data for a countermeasure list indicating a list of the countermeasure means for the control model, and output the data for the countermeasure list to the development system handling executable models to thereby cause the development system handling executable models to reflect the countermeasure list in the control model.
  • the software development system may be further provided with an attack database that retains data of one or more attacks on information security
  • the circuitry may, with regard to the individual elements making up the control model, extract data of corresponding attacks from the attack database to thereby create and output data for an attack list indicating a plurality of the attacks on the control model, and output the data for the attack list to the development system handling executable models to thereby cause the development system handling executable models to reflect the attack list in the contract model and perform a simulation to assess source code of the control model in which the attack list has been reflected.
  • the circuitry may have the control model created by the development system handling executable models input thereto, group a plurality of the elements making up the input control model in such a way that a predetermined granularity is implemented, and set incoming/outgoing connections of a dataflow for the plurality of grouped elements to thereby output the plurality of grouped elements as the individual elements of the control model.
  • the circuitry may, as the predetermined granularity, group the plurality of elements in such a way as to form a plurality of elements that are not connected to elements to be protected as information assets and a plurality of elements that are connected to the elements to be protected as the information assets.
  • the circuitry may, as the predetermined granularity, group the plurality of elements in such a way that pattern matching is performed using a design pattern corresponding to a predetermined element type, and a specific element matching the design pattern serves as a group boundary.
  • the predetermined granularity may be a preset upper value for a number of times that grouping is to be performed
  • the circuitry may group a plurality of elements included in a block diagram until reaching the preset upper value for the number of times that grouping is to be performed.
  • the individual elements of the control model created by the development system handling executable models may have trust boundary information indicating whether the individual elements are inside or outside of a trust boundary for security, and the circuitry may determine whether the individual elements are inside or outside of the trust boundary, based on the trust boundary information possessed by the individual elements of the control model created by the development system handling executable models, and use data of the threats for the elements that are outside of the trust boundary from among the data of the corresponding threats extracted from the threat database, to create and output the data for the threat list indicating the plurality of threats for the control model.
  • the model-based development system may create the control model from the design information, generate source code from the created control model, perform a simulation to assess the generated source code, and cause the control model to be revised by feeding an assessment result for the source code back to the control model.
  • a non-transitory recording medium is a computer-readable non-transitory recording medium having recorded thereon a program that performs a threat analysis for a control model which is created from design information for a development target by a development system handling executable models and is an executable model in which the development target is simulated, the program, when executed by a processor, causing the processor to execute a method including: with regard to individual elements of the control model created by the development system handling executable models, extracting data of corresponding threats from a threat database that retains data of one or more threats that are factors that cause risks in information security to occur, and thereby creating and outputting data for a threat list indicating a plurality of threats for the control model.
  • the method may further include: inputting of the control model created by the development system handling executable models, and grouping a plurality of the elements included in a block diagram expressing the input control model, in such a way that a predetermined granularity is implemented; and setting incoming/outgoing connections of a dataflow for the plurality of grouped elements, and thereby outputting the plurality of grouped elements as the individual elements of the control model.
  • the individual elements of the control model created by the development system handling executable models may have trust boundary information indicating whether the individual elements are inside or outside of a trust boundary for security, and the method may further include: setting information indicating whether the individual elements are inside or outside of the trust boundary, in each of the plurality of grouped elements.
  • the individual elements of the control model created by the development system handling executable models may have the trust boundary information indicating whether the individual elements are inside or outside of the trust boundary for security
  • the method may further include: acquiring the individual elements of the control model created by the development system handling executable models; comparing the acquired individual elements of the control model and each of the one or more threats retained in the threat database to extract the data of the corresponding threats from the threat database; determining whether the individual elements are inside or outside of the trust boundary, based on the trust boundary information possessed by the individual elements of the control model created by the development system handling executable models; and using data of the threats for the elements that are outside of the trust boundary from among the data of the corresponding threats extracted from the threat database, to create and output the data for the threat list indicating the plurality of threats for the control model.
  • Fig. 1 is a configuration diagram depicted on the basis of the flow of data in a software development system 1 according to embodiment 1.
  • Fig. 2 is a flowchart depicting an overview of all of the processing of the software development system 1 according to embodiment 1.
  • the software development system 1 is provided with a model-based development system 10, a threat analysis system 20, and a granularity conversion unit 25.
  • the software development system 1 operates on a computer such as a personal computer, and is operated by a user of the software development system 1 with information necessary for development being input thereto.
  • Fig. 1 the way in which the model-based development system 10 and the threat analysis system 20 operate while cooperating with each other is depicted on the basis of the flow of data.
  • the software development system 1 is not restricted to the case where the model-based development system 10 is included and may be a development system that handles executable models; however, hereinafter, the case where the model-based development system 10 is included is described as an example.
  • the model-based development system 10 depicted in Fig. 1 is provided with a control model creation tool unit 100, an automatic code generation tool unit 120, and an assessment tool unit 140.
  • the control model creation tool unit 100 creates a control model from design information. More specifically, the control model creation tool unit 100 has information for creating a control model 110, namely a model in which a development target is simulated, input thereto by means of a user operation, and creates the control model 110 from the input information.
  • control model creation tool unit 100 has input thereto, by means of user operations, elements that are necessary for control model simulation, input/output for the each element, dataflow, and the like from system design specifications and so forth, and also information and the like regarding trust boundaries and grouping that is necessary for a threat analysis to be performed by the threat analysis system 20.
  • the control model creation tool unit 100 then creates the control model 110, which is expressed by means of a block diagram made up of the four basic arithmetic operations, differentiation/integration, conditional expressions, iteration, and the like, from the input information.
  • the information regarding trust boundaries and grouping that is necessary for the threat analysis to be performed by the threat analysis system 20 and the like may be input automatically by the granularity conversion unit rather than the control model creation tool unit 100. Furthermore, the information regarding trust boundaries and grouping that is necessary for the threat analysis to be performed by the threat analysis system 20 and the like may be input by the threat analysis system 20 by means of a user operation. Furthermore, the control model 110 stores information regarding the flow of data, described using a data flow diagram (DFD).
  • DFD data flow diagram
  • control model creation tool unit 100 revises the created control model 110 and reflects (feeds back) content that is based on threat list data 210 in the control model 110, on the basis of an assessment result produced by the assessment tool unit 140, by means of a user operation.
  • reflecting content in the control model 110 means revising the control model 110 in such a way that a countermeasure for a threat is implemented therein. The details thereof are described later.
  • the automatic code generation tool unit 120 generates source code from the control model 110 created by the control model creation tool unit 100. More specifically, the automatic code generation tool unit 120 generates executable source code 130 from the control model 110 created by the control model creation tool unit 100.
  • the source code 130 includes the source code for a program for a development target (a device, module, or the like that is the development target).
  • the assessment tool unit 140 performs a simulation to assess the source code generated by the automatic code generation tool unit 120.
  • the assessment tool unit 140 feeds the assessment result back to the control model creation tool unit 100 to thereby cause the control model creation tool unit 100 to revise the control model 110.
  • the assessment tool unit 140 performs a simulation to execute the source code generated by the automatic code generation tool unit 120, examines the operation of the source code for functions of the development target, and outputs an assessment result 150 that includes whether or not the development target has operated appropriately.
  • the granularity conversion unit 25 depicted in Fig. 1 converts (groups) a plurality of elements included in the control model 110 created by the control model creation tool unit 100 into a granularity appropriate for a threat analysis by the threat analysis system 20.
  • the granularity conversion unit 25 outputs the control model 110 including the plurality of grouped elements to the threat analysis system 20. This is because, if the control model 110 is output to the threat analysis system 20 as it is and used for a threat analysis, the threat analysis granularity is small and a very large number of threats are extracted. That is, if the threat analysis granularity is small, the feedback to the control model creation tool unit 100 is no longer realistic.
  • the granularity conversion unit 25 has the control model 110 created by the model-based development system 10 input thereto, and groups the plurality of elements making up the input control model 110 so as to achieve a prescribed granularity.
  • the granularity conversion unit 25 sets incoming/outgoing connections of the dataflow for the plurality of grouped elements to thereby output the plurality of grouped elements to the threat analysis system 20 as individual elements of the control model 110.
  • the granularity conversion unit 25, as the predetermined granularity may group the plurality of elements so as to form a plurality of elements that are not connected to elements to be protected as information assets and a plurality of elements that are connected to elements to be protected as information assets.
  • the granularity conversion unit 25, as the predetermined granularity may group the plurality of elements in such a way that pattern matching is performed using a design pattern corresponding to a predetermined element type and a specific element matching the design pattern serves as a group boundary.
  • examples of a design pattern are the group surrounded by the dashed line in the upper left of Fig. 5C described later on and the group surrounded by the dashed line in the right half of the diagram.
  • the granularity conversion unit 25 may set the specific element as a group boundary.
  • a specific element for example, is a module connected to an external network such as a gateway and is where a trust boundary is generally drawn.
  • the prescribed granularity may be a preset upper value for the number of times that grouping is to be performed.
  • the granularity conversion unit 25 preferably groups the plurality of elements until reaching the preset upper value for the number of times that grouping is to be performed.
  • the individual elements of the control model 110 created by the model-based development system 10 have trust boundary information indicating whether the individual elements are inside or outside of a trust boundary for security. Therefore, the granularity conversion unit 25 may set information indicating whether inside or outside of a trust boundary, for each of the plurality of grouped elements.
  • the threat analysis system 20 depicted in Fig. 1 is provided with a threat analysis tool unit 200 and a threat database (DB) 240.
  • DB threat database
  • the threat DB 240 is a database that retains data of one or more threats which are factors that cause risks in information security to occur.
  • the types of threats and the conditions under which the threats occur are stored in the threat DB 240.
  • a threat model 245 is expressed by means of the DFD in Fig. 6 described later on and the threat DB 240, and, for example, is the result of investigating the kind of security threats to which the development target is exposed and whether there is a possibility that the development target may be attacked.
  • the threat analysis tool unit 200 extracts data of corresponding threats from the threat DB 240 to thereby create and output data for a threat list that indicates a plurality of threats for the control model 110.
  • the control model 110 is created from design information of the development target by the model-based development system 10 for carrying out model-based development, and simulates the development target.
  • the threat analysis tool unit 200 analyses vulnerabilities for the control model 110 and outputs data for the threat list (threat list data 210), with the threat model 245 as output of the granularity conversion unit 25 and the threat model 245 and the threat DB 240 as input for the threat analysis tool unit 200.
  • the threat model 245 is expressed by means of the DFD in Fig. 6 described later on and the threat DB 240, and, with regard to the control model 110, data of threats that match threats retained by the threat DB 240 are extracted to create and output the threat list data 210.
  • the threat analysis tool unit 200 may create and output the threat list data 210 indicating a plurality of threats for the control model 110, using data of threats for elements outside of the trust boundary, from among data of the corresponding threats extracted from the threat DB 240.
  • the threat analysis tool unit 200 may analyze whether or not there is a flow of data that crosses the trust boundary of the control model 110, and, if there is a flow of data that crosses the trust boundary, may determine that there is a threat and create and output the threat list data 210 including data of the determined threat.
  • Fig. 2 is a flowchart depicting a processing overview of the software development system 1 according to embodiment 1.
  • the user causes the control model creation tool unit 100 to create the control model 110 (S10).
  • the threat analysis tool unit 200 creates the threat list data 210 from the control model 110 for which the granularity has been converted (S20).
  • control model creation tool unit 100 by means of the user, causes content that has been fed back based on the threat list data 210 to be reflected in the control model 110 (S30).
  • the assessment tool unit 140 performs a simulation to assess the source code of the control model 110, which has been generated by the automatic code generation tool unit 120 and had the content reflected therein (S40).
  • the user determines whether or not there is a no-good (NG) portion in the assessment result of the assessment tool unit 140 (S50). If there is an NG portion (yes in S50), the control model creation tool unit 100 is made to revise the control model 110 with respect to said portion by means of a user operation (S60), and processing proceeds to S20. However, if there is no NG portion (no in S50), processing is terminated.
  • NG no-good
  • the software development system 1 in the present embodiment it is possible to perform a threat analysis and implement a countermeasure for a threat prior to a program for a development-target device being implemented in the device, and it is therefore possible to improve development efficiency in system development that is based on the model-based method.
  • control target for which a control model is created
  • granularity conversion for which a trust boundary
  • control model for which a trust boundary is set for which a trust boundary is set
  • trust boundary setting operation for which a control model is set
  • Fig. 3 is a configuration diagram of an in-vehicle system 300 serving an example of a development target.
  • Fig. 3 depicts an overview of the internal configuration of the in-vehicle system 300 and the relationship between the outside and the in-vehicle system 300.
  • An external server 330 is connected to the in-vehicle system 300 via a communication channel.
  • the in-vehicle system 300 has an in-vehicle GW (gateway) 310, a communication unit 320, and various types of devices.
  • the communication unit 320 is connected to the in-vehicle GW (gateway) 310.
  • the various types of devices are connected to the in-vehicle GW 310 via an in-vehicle LAN such as a CAN.
  • an in-vehicle LAN such as a CAN.
  • information relating to map data, ECU update programs, other telematics services, and the like enters via the in-vehicle GW 310 from the external server 330.
  • Fig. 4 is a system configuration diagram of the in-vehicle system 300 depicted in Fig. 3.
  • An external telematics service is connected to the in-vehicle GW310 via a telematics device 340.
  • an OBD-II 350 which is a communication port for connecting a diagnostic device, is connected to the in-vehicle GW 310.
  • the telematics device 340 and the OBD-II 350 correspond to the communication unit 320 in Fig. 3.
  • the in-vehicle GW 310 is connected to the in-vehicle LAN.
  • ECUs such as an operation ECU 370, a display ECU 380, and a drive ECU 390 are connected to the in-vehicle GW 310 via the in-vehicle LAN.
  • the operation ECU 370 is a steering operation ECU, an accelerator operation ECU, a turn signal operation ECU, or the like.
  • the display ECU 380 is a speed display ECU, a turn signal display ECU, or the like.
  • the drive ECU 390 is a tire/suspension control ECU, an engine control ECU, or the like.
  • Fig. 5A is a diagram for illustrating an example of a granularity conversion according to embodiment 1.
  • Fig. 5A depicts an example of a control model that is made up of element 60 to element 65 and is referred to as PID control.
  • the user uses the granularity conversion unit 25 to perform grouping (granularity conversion) on the block diagram in such a way that a granularity (number of divisions) that is appropriate for a threat analysis is achieved.
  • the portion surrounded by the dashed line in Fig. 5A (the grouping region in the diagram) is grouped into one group. That is, grouping is performed in such a way that the plurality of elements (element 60 to element 65) included in the block diagram depicted in Fig. 5A form one group. More specifically, the user selects targets for grouping by means of a GUI provided by the granularity conversion unit 25, and the targets are thereby grouped and the granularity is increased.
  • the threat analysis tool unit 200 performs a threat analysis with the targets grouped by the granularity conversion unit 25 as one element of the control model 110.
  • control model creation tool unit 100 or the threat analysis tool unit 200 may have a function that performs grouping with respect to the control model 110.
  • Figs. 5B and 5C are diagrams depicting examples of block diagrams for illustrating a method in which the granularity conversion unit 25 according to embodiment 1 performs grouping automatically.
  • Figs. 5D and 5E are flowcharts depicting an example of processing in which the granularity conversion unit 25 according to embodiment 1 performs grouping automatically.
  • Fig. 5B depicts an example of a block diagram representing portions of the control model 110 before grouping is performed.
  • Fig. 5C depicts an example of a block diagram representing portions of the control model 110 after grouping has been performed.
  • the granularity conversion unit 25 is made to designate (specify) information assets to be protected, with respect to the block diagram depicted in Fig. 5B, for example (S11). More specifically, the user uses the granularity conversion unit 25 to specify information assets to be protected. The way in which the data flows is then added, and read/write information for the information assets to be protected is also entered. In this way, the user causes the granularity conversion unit 25 to embody threats for the block diagram depicted in Fig. 5B. At such time, the granularity conversion unit 25 places elements that do not handle information assets to be protected into one group (S12). Here, the group in the bottom left depicted in Fig.
  • the granularity conversion unit 25 groups the plurality of elements included in the block diagram so as to form a plurality of elements that are not connected to elements to be protected as information assets and a plurality of elements that are connected to elements to be protected as information assets.
  • the granularity conversion unit 25 prepares a design pattern according to the types of elements included in the block diagram depicted in Fig. 5B (S13).
  • the granularity conversion unit 25 performs pattern matching on the plurality of elements included in the block diagram depicted in Fig. 5B using the design pattern corresponding to the types of elements prepared in S13 (S14).
  • the granularity conversion unit 25 determines whether a specific element matching the design pattern has appeared in the plurality of elements included in the block diagram depicted in Fig. 5B (S15), and, if a specific element has appeared (yes in S15), the specific element is set as a group boundary (S16). However, if a specific element has not appeared (no in S15), the granularity conversion unit 25 terminates the processing.
  • the granularity conversion unit 25 may group the plurality of elements included in the block diagram, until reaching a preset upper value for the number of times that grouping is to be performed.
  • a specific element for example, is a module connected to an external network such as a gateway and is where a trust boundary is generally drawn.
  • the design pattern may be determined according to the types in Fig. 7 described later on, with the output side of an externally connected telematics device or OBD-II always serving as a group boundary, or the trust boundary always serving as a group boundary.
  • Fig. 6 is a diagram depicting a data flow diagram used to express a threat model.
  • Fig. 6 depicts an example of the case where a trust boundary has been set for the system configuration depicted in Fig. 4 when expressed as a dataflow diagram.
  • a threat model is expressed using a data flow diagram obtained by grouping several elements of a block diagram to achieve a granularity enabling threat analysis and adding a trust boundary.
  • the operation ECU 370 is a steering operation ECU, an accelerator operation ECU, a turn signal operation ECU, or the like, and is connected to the in-vehicle GW 310 via the in-vehicle LAN.
  • the display ECU 380 is a speed display ECU, a turn signal display ECU, or the like, and is connected to the in-vehicle GW 310.
  • the drive ECU 390 is a tire/suspension control ECU, an engine control ECU, or the like, and is connected to the in-vehicle GW 310.
  • the trust boundary is depicted using a dashed line.
  • the trust boundary means that the devices inside the trust boundary are able to trust each other but the devices outside of the trust boundary are not always able to be trusted. It should be noted that the trust boundary is input by the user of the software development system 1 operating a personal computer or the like.
  • the server 330 which provides an external telematics service, connects to the telematics device 340 via a 3G network 332, and is thereby connected to the in-vehicle GW 310.
  • a diagnostic device 400 connects to the OBD-II 350 via an IS014230 connector 402, and is thereby connected to the in-vehicle GW 310.
  • the telematics device 340 and the OBD-II 350 are outside of the trust boundary. Therefore, the in-vehicle system 300 in which the in-vehicle GW 310, the operation ECU 370, the display ECU 380, the drive ECU 390, and the like are inside the trust boundary is not always able to trust the telematics device 340 and the OBD-II 350.
  • Fig. 7 is a diagram depicting a database for the control model 110 containing information on the trust boundary depicted in Fig. 6.
  • This database is created by the aforementioned control model creation tool unit 100.
  • This database stores information indicating a trust boundary and indicating that there are devices included therein.
  • control model creation tool unit 100 handles only block diagrams that indicate the control model 110, and the threat analysis tool unit 200 may create this database on the basis of the information of a block diagram for the control model 110 created by the control model creation tool unit 100.
  • ID indicates a number for each element and is automatically assigned by the control model creation tool unit 100. Furthermore, “Name” indicates the name of each element and is input by the user. "Incoming ID (In)” indicates that data has come from the element of the displayed ID. “Outgoing ID (Out)” indicates that data will go to the element of the displayed ID. "Type” indicates the type of the element. "Trust In/Out” indicates whether the element indicated by the “ID” is inside or outside of the trust boundary, or whether the element crosses the trust boundary. Here, “Boundary” in the "Trust In/Out” column indicates that the element crosses the trust boundary. Furthermore, “Block Diagram ID” is the ID of the block diagram included in the element.
  • Fig. 8 is a flowchart depicting processing for creating the control model 110 according to embodiment 1.
  • the user of the software development system 1 uses a GUI or the like provided by the control model creation tool unit 100 to input the "Name" of one element that is to make up the control model 110 (S100).
  • An ID is automatically assigned by the control model creation tool unit 100.
  • the user uses the GUI or the like provided by the control model creation tool unit 100 to set the incoming/outgoing connections for said element (S110). For example, the user inputs the ID of an element that connects prior to said element, and inputs the ID of an element that connects subsequent to said element. It should be noted that a plurality of elements are input if there are a plurality of elements that connect prior or subsequent to said element.
  • the user uses the GUI or the like provided by the control model creation tool unit 100 to set other information such as the type of said element (S120).
  • the user uses the GUI or the like provided by the control model creation tool unit 100 to set the trust boundary for all of the elements (S140).
  • Figs. 9A and 9B are diagrams for illustrating an operation for when a trust boundary is set for the control model 110.
  • Fig. 9A depicts an operation scenario in which the user selects an element using a mouse cursor
  • Fig. 9B depicts a scenario in which two trust boundaries are set.
  • Src 1, T1, and Snk 1 depicted in Figs. 9A and 9B are elements of a data flow diagram (DFD), and represent the input, modification, and output of data in a source-transfer-sink configuration.
  • DDD data flow diagram
  • a trust boundary A that includes Src 1 and T1 such as that depicted in Fig. 9B is created.
  • Fig. 10 is a flowchart depicting processing for a trust boundary setting operation.
  • the user of the software development system 1 selects a "Trust Boundary Creation” tool in the GUI or the like provided by the control model creation tool unit 100 (S200).
  • the selected tool enters an operation input waiting state (S210).
  • the user selects an element using the mouse cursor (S220). Specifically, an operation is performed as described in Figs. 9A and 9B, and therefore a description thereof is omitted.
  • the tool sets the selected element to "In” in order to be included inside the trust boundary (S240), and processing returns to S210.
  • Fig. 11 is a diagram depicting an example of data retained by the threat DB 240 according to embodiment 1.
  • the threat DB 240 depicted in Fig. 11 stores a description of a threat, the condition under which that threat occurs, a type indicating the source of that threat, information indicating whether that source is inside or outside of the trust boundary, and a threat ID that is used when specifying a countermeasure for the threat.
  • Fig. 12 is a diagram depicting an example of the threat list data 210 according to embodiment 1.
  • the threat list data 210 is created by means of the threat analysis tool unit 200, and indicates a plurality of threats for the control model 110.
  • the threat list data 210 depicted in Fig. 12 stores a target name, a target ID, a threat description, a threat ID, a type, and information indicating whether inside or outside of the trust boundary. As mentioned above, this threat list data 210 is created, from the control model 110 and the threat DB 240, and output by the threat analysis tool unit 200.
  • Fig. 13 is a flowchart depicting processing for creating the threat list data 210 according to embodiment 1.
  • the threat analysis tool unit 200 uses the database for the control model 110 depicted in Fig. 7, for example, and the threat DB 240 depicted in Fig. 11, for example, to create the threat list data 210.
  • the threat analysis tool unit 200 acquires one unprocessed item from among the elements of the control model 110 (S300).
  • the threat analysis tool unit 200 determines whether or not an unprocessed item has been acquired (S310). If an unprocessed item has not been acquired (no in S310), the threat analysis tool unit 200 terminates the processing and outputs the created threat list data 210.
  • Processing proceeds to S340 if there is a matching item among the threats retained by the threat DB (yes in S330), and processing returns to S300 if not (no in S330).
  • ID 350
  • OBD-II the threat analysis tool unit 200
  • there a plurality of types in the threat DB 240 where there are a plurality of the same type with different IDs
  • these may be processed collectively.
  • the threat analysis tool unit 200 determines the width of a target to be extracted in accordance with the section of the user (S340). It should be noted that the width of the extraction target may be preselected prior to the threat analysis tool unit 200 being used, and is preferably selected before the threat list data 210 is created.
  • the processing of S350 is skipped and the threat data of the threat DB having the "Type" for which a search was performed in S320 is extracted and added to the threat list data 210 (S360).
  • the threat analysis tool unit 200 determines whether the "Type" for which a search was performed in S320 is outside or across the trust boundary (S350), and, if that is the case, namely that there is a dataflow that is crossing the trust boundary (yes in S350), extracts the threat data of the threat DB having the "Type" for which a search was performed in S320 and adds such to the threat list data 210 (S360).
  • the threat analysis tool unit 200 extracts the threat data of the threat DB having "OBD-II", which is the "Type” for which a search was performed in S320, and adds such to the threat list data 210.
  • the threat list data 210 is created with a wide extraction target, or the threat list data 210 is created with a narrow extraction target in that elements inside the trust boundary are considered as not corresponding to threat candidates and are excluded from the extraction target.
  • Fig. 14A is a diagram depicting a data flow diagram for a control model in which feedback is performed on the basis of a threat list according to embodiment 1.
  • Fig. 14B is a diagram depicting a database for the control model 110 in which feedback has been implemented on the basis of a threat list according to embodiment 1. It should be noted that, in Fig. 14B, diagonal lines are drawn in portions that have been revised from the control model 110 created by the control model creation tool unit 100 depicted in Fig. 7.
  • the user of the software development system 1 reflects (feeds back) the threat list indicated in the threat list data 210 created and output by the threat analysis tool unit 200, in the control model 110, using the control model creation tool unit 100. More specifically, as depicted in Figs. 14A and 14B, the user revises the control model 110 in such a way that countermeasures for threats are implemented therein, on the basis of the threat list indicated in the threat list data 210 as depicted in Fig. 11.
  • Fig. 15 is a diagram depicting a system development procedure according to a V-shaped model in embodiment 1.
  • a threat analysis is performed at an upstream stage of system development and countermeasures for threats are reflected in the control model 110 on the basis of the threat list indicated in the output threat list data 210. That is, it becomes possible to implement countermeasures for threats at an upstream stage of system development, namely the system development stage.
  • control model creation tool unit 100 may be made to revise the control model 110 in such a way that countermeasures for threats are implemented therein, by the threat analysis system creating countermeasures on the basis of the threat list data 210 and feeding the countermeasures back to the control model creation tool unit 100.
  • this case will be described as embodiment 2.
  • Fig. 16 is a configuration diagram depicted on the basis of the flow of data in a software development system 1A according to embodiment 2.
  • the same elements as in Fig. 1 are denoted by the same reference numbers, and a detailed description thereof is omitted.
  • the configuration of a threat analysis system 20A is different from the software development system 1 according to embodiment 1.
  • the threat analysis system 20A depicted in Fig. 16 has a different configuration from that of the threat analysis system 20 according to embodiment 1 in that a countermeasure list creation tool unit 220 and a countermeasure DB 250 have been added.
  • a description will be given focusing on the points that are different from embodiment 1.
  • the countermeasure DB 250 is a database that retains data of countermeasure means for each of one or more threats.
  • the countermeasure DB 250 stores countermeasures for each of the threats. It should be noted that in the case where there are a plurality of countermeasures for a threat, the countermeasure DB 250 may store the plurality of countermeasures in descending order of priority in order to increase processing efficiency.
  • the countermeasures for each of the threats stored in the countermeasure DB 250 are created from a countermeasure model 255 in which the attack content of each of the plurality of threats and countermeasure methods therefor are modeled, for example.
  • the countermeasure list creation tool unit 220 extracts, from the countermeasure DB 250, countermeasure means for each of the plurality of threats included in the threat list data 210 created and output by the threat analysis tool unit 200, to thereby create and output data of a countermeasure list that indicates a list of countermeasure means for the control model 110.
  • the countermeasure list creation tool unit 220 outputs the data of the countermeasure list to the model-based development system 10, to thereby cause the model-based development system 10 to reflect the countermeasure list in the control model 110.
  • the countermeasure list creation tool unit 220 creates data for a countermeasure list (countermeasure list data 230) that constitutes countermeasures for threats, from the threat list data 210 and the countermeasure DB 250, and outputs the data of the countermeasure list to the control model creation tool unit 100.
  • the control model creation tool unit 100 then reflects the countermeasure list indicated in the input countermeasure list data 230, in the control model 110.
  • control model creation tool unit 100 revises the created control model 110 into a control model 110 in which countermeasures for threats included in the countermeasure list indicated in the countermeasure list data 230 have been implemented.
  • Fig. 17 is a flowchart depicting a processing overview of the software development system 1A according to embodiment 2.
  • the same elements as in Fig. 2 are denoted by the same reference numbers, and a detailed description thereof is omitted.
  • the threat analysis tool unit 200 creates the threat list data 210 from the control model 110 for which the granularity has been converted.
  • the countermeasure list creation tool unit 220 creates the countermeasure list data 230 by extracting, from the countermeasure DB 250, countermeasure means for each of the plurality of threats (threat list) included in the threat list data 210, and outputs the countermeasure list data to the control model creation tool unit 100 (S25).
  • control model creation tool unit 100 causes the countermeasures for the threats indicated in the countermeasure list data 230 to be reflected in the control model 110 (S30A).
  • the software development system 1A in the present embodiment it is possible to perform a threat analysis and implement countermeasures for threats prior to a program for a development-target device being implemented in the device, and it is therefore possible to improve development efficiency in system development that is based on the model-based method.
  • Fig. 18 is a diagram depicting an example of data retained by the countermeasure DB 250 according to embodiment 2.
  • the countermeasure DB 250 depicted in Fig. 18 stores a threat ID, a countermeasure ID that indicates a countermeasure for the threat indicated by the threat ID, and countermeasure content that indicates a method and content with which the countermeasure indicated by the countermeasure ID is carried out.
  • Fig. 19 is a diagram depicting an example of the countermeasure list data 230 according to embodiment 2.
  • the countermeasure list data 230 is data that indicates a list of countermeasure means for the control model 110.
  • the countermeasure list data 230 depicted in Fig. 19 has stored therein a target name, a target ID, a threat ID, whether inside/outside the trust boundary, a countermeasure ID, and a countermeasure location.
  • the target means a target for which a countermeasure is to be implemented.
  • this countermeasure list data 230 is created from the threat list data 210 and the countermeasure DB 250 and output by the countermeasure list creation tool unit 220.
  • ID 1
  • the target name is "OBD-II”
  • the threat ID is "Unauthorized device”
  • the target ID is "Filter”
  • the countermeasure location is "Between 340 and 310”, namely that the filter is to be set up between 340 and 310.
  • ID 2 hereinafter, and therefore a description thereof is omitted.
  • Fig. 20 is a flowchart depicting creation processing performed by the countermeasure list creation tool unit 220 according to embodiment 2.
  • the countermeasure list creation tool unit 220 creates the countermeasure list data 230 using the threat list data 210 depicted in Fig. 12, for example, and the countermeasure DB 250 depicted in Fig. 18, for example.
  • the countermeasure list creation tool unit 220 acquires one unprocessed item from the threat list included in the threat list data 210 (S400).
  • the countermeasure list creation tool unit 220 determines whether or not an unprocessed item has been acquired (S410). If an unprocessed item has not been acquired (no in S410), the countermeasure list creation tool unit 220 terminates the processing and outputs the created countermeasure list data 230.
  • processing proceeds to S440 and a countermeasure ID is added to the countermeasure list data 230 (S440).
  • the countermeasure list creation tool unit 220 then, from the "Countermeasure content" corresponding to the matching "Threat ID” retained by the countermeasure DB 250, refers to information of the control model 110, specifies countermeasure content, and adds the countermeasure content corresponding to the threat ID to the countermeasure list data 230 (S450).
  • it is retrieved that there is a "Threat ID” that matches ID 1 depicted in Fig. 18 (of the countermeasure DB 250), namely an unauthorized device.
  • the "Countermeasure ID” of said "Threat ID” retained in the countermeasure DB 250 is that of a filter and the "Countermeasure location" is that of inserting between, and therefore the countermeasure list creation tool unit 220 specifies the place where a filter is to be inserted from the control model 110 depicted in Figs. 6 and 7.
  • the countermeasure list creation tool unit 220 adds this information to the countermeasure fist data.
  • the countermeasure list creation tool unit 220 queries the user as to whether or not a countermeasure is to be added (S470).
  • the countermeasure list creation tool unit 220 adds a countermeasure to the countermeasure DB 250 (S480), and processing proceeds to S440 for that countermeasure to be reflected in the countermeasure list data 230.
  • the countermeasure list data 230 created in this way is output to the control model creation tool unit 100 of the model-based development system 10.
  • the control model creation tool unit 100 reflects the countermeasure list indicated in the countermeasure list data 230, in the control model 110.
  • Fig. 21 is a flowchart depicting processing for reflecting a countermeasure list in the control model 110.
  • the control model creation tool unit 100 causes the countermeasure list indicated in the countermeasure list data 230 depicted in Fig. 19, for example, to be reflected in the control model 110, and creates a database for the control model 110 depicted in Fig. 14B, for example.
  • the control model creation tool unit 100 acquires one unprocessed item from the countermeasure list indicated in the countermeasure list data 230 (S500).
  • control model creation tool unit 100 determines whether or not an unprocessed item has been acquired (S510). If an unprocessed item has not been acquired (no in S510), the control model creation tool unit 100 terminates the processing and outputs the control model 110 created up to that point.
  • control model creation tool unit 100 If the control model creation tool unit 100 has acquired an unprocessed item in S510 (yes in S510), the relationship between the countermeasure target (the "Target name” column in Fig. 19) and the "Countermeasure location” is determined (S520).
  • the countermeasure list indicated in the countermeasure list data 230 it is possible for the countermeasure list indicated in the countermeasure list data 230 to be reflected in the control model 110 using the control model creation tool unit 100, in other words, automatically by means of a computer program.
  • Fig. 22 is a configuration diagram depicted on the basis of the flow of data in a software development system 1 B according to embodiment 3.
  • the same elements as in Figs. 1 and 16 are denoted by the same reference numbers, and a detailed description thereof is omitted.
  • the software development system 1B depicted in Fig. 22 is different from the software development system 1A according to embodiment 2 in that a simulation function adding system 26 has been added.
  • a description will be given focusing on the points that are different from embodiment 2.
  • the simulation function adding system 26 is provided with an attack list creation tool unit 260 and an attack DB 270.
  • the attack DB 270 is a database that retains data of each of one or more attacks on information security.
  • the attack DB 270 stores attack methods and attack procedures, and stores content corresponding to the threat DB 240.
  • the attack methods and attack procedures stored in the attack DB 270 are created from an attack model 275 obtained by modeling attack content (threat description) constituting a threat and a procedure for that attack content.
  • the attack list creation tool unit 260 extracts data of corresponding attacks from the attack DB 270 with respect to the individual elements making up the control model 110, to thereby create and output data of an attack list (attack list data 265) that indicates a plurality of attacks on the control model 110. Furthermore, the attack list creation tool unit 260 outputs the attack list data 265 to the model-based development system 10 to thereby cause the model-based development system 10 to reflect the attack list indicated in the attack list data 265, in the control model 110, and cause a simulation to be performed to assess the source code of the control model 110 in which the attack list has been reflected.
  • the attack list creation tool unit 260 creates the attack list data 265 from the control model 110 and the attack DB 270, and outputs such to the control model creation tool unit 100.
  • the control model creation tool unit 100 then adds, to the control model 110, a function for simulating an attack on the basis of an attack procedure from within the attack list indicated in the attack list data 265 created by the attack list creation tool unit 260.
  • the assessment tool unit 140 is able to simulate an attack on the control model 110, and it is therefore possible to confirm the effectiveness of a security countermeasure function at an upstream stage of system development, namely the system development stage.
  • Fig. 23 is a flowchart depicting a processing overview of the software development system 1B according to embodiment 3.
  • the same elements as in Figs. 2 and 17 are denoted by the same reference numbers, and a detailed description thereof is omitted.
  • control model creation tool unit 100 causes countermeasures for threats indicated in the countermeasure list data 230 to be reflected in the control model 110.
  • control model creation tool unit 100 causes attack content from within the attack list indicated in the attack list data 265 and a procedure for the attack content to be reflected in the control model 110 (S30B). More specifically, the control model creation tool unit 100 adds, to the control model 110, a function for simulating an attack on the basis of the attack content from within the attack list indicated in the attack list data 265 and the procedure for the attack content.
  • control model creation tool unit 100 may display the attack list indicated by the attack list data 265 automatically by means of a GUI, and the user, using the GUI, may select which attack from within the attack list is to be added to the control model 110, and this may be arranged in the dataflow, or the control model creation tool unit 100 may carry out everything automatically.
  • the assessment tool unit 140 then performs a simulation to assess the source code of the control model 110 that has been generated by the automatic code generation tool unit 120 and had the content reflected therein, and also to perform an attack on the control model 110 (S40).
  • attack DB 270 the attack list data 265, processing performed by the attack list creation tool unit 260, and the like.
  • Fig. 24 is a diagram depicting an example of data retained by the attack DB 270 according to embodiment 3.
  • the attack DB 270 depicted in Fig. 24 stores an "Attack Description” that indicates the content of an attack, a "Type” that indicates an attack target, "Trust In/Out” that indicates whether the source of an attack is inside or outside of the trust boundary, and an "Attack Procedure” that indicates the procedure of an attack on an attack target.
  • Type indicates an "OBD-II”
  • Trust In/Out indicates outside, namely that the source of the attack is outside of the trust boundary
  • Attack Procedure indicates that the prior element is replaced with an attack tool.
  • ID 2 hereinafter, and therefore a description thereof is omitted
  • Fig. 25 is an example of the attack list data 265 according to embodiment 3.
  • the attack list data 265, as mentioned above, is data that indicates a list of attacks on the control model 110.
  • the attack list data 265 depicted in Fig. 25 stores the "Attack Description", "Type”, “Trust In/Out”, and "Attack Procedure".
  • Fig. 26 is a flowchart depicting creation processing of the attack list creation tool unit 260 according to embodiment 3.
  • the attack list creation tool unit 260 creates the attack list data 265 using the control model 110 depicted in Fig. 6, for example, and the attack DB 270 depicted in Fig. 24, for example.
  • the attack list creation tool unit 260 acquires one unprocessed item from the attacks included in the attack DB 270 (S600).
  • the attack list creation tool unit 260 determines whether or not an unprocessed item has been acquired (S610). If an unprocessed item has not been acquired (no in S610), the attack list creation tool unit 260 terminates the processing and outputs the created attack list data 265.
  • the attack list creation tool unit 260 determines whether the "Type" of the acquired attack matches an extraction condition of being included in the elements within the control model 110 (S620), and, if matching (yes in S630), adds the attack to the attack list data 265 (S640).
  • the attack list creation tool unit 260 determines whether there is an item that matches the "Type" included in the attack acquired from the attack DB 270 in S600, in the elements within the control model 110 depicted in Figs. 6 and 7. For example, in the case where ID 1 of the attack DB 270 depicted in Fig. 21 is acquired, since the "Type" of ID 1 is the OBD-II and "OBD-II" is also in the DB of the control model 110 depicted in Fig. 7, in S640, the attack of ID 1 is added to the attack list data 265.
  • Fig. 27 is a diagram depicting an example of the control model 110 to which an attack simulation function has been added according to embodiment 3.
  • Fig. 28A is a diagram depicting an example of the case where a countermeasure is implemented on the control model 110 depicted in Fig. 27.
  • Fig. 29 is a diagram depicting a portion of the format of a CAN message. Fig. 29 depicts only the fields relating to the present embodiment.
  • Fig. 27 depicts an example of the case where a function that attacks the OBD-II 350, which is one of the elements of the control model 110 depicted in Fig. 6, has been added.
  • an attack tool 500 has been added as an element that connects to the OBD-II 350.
  • an unauthorized CAN message may be input to the in-vehicle LAN from the OBD-II 350 for the display ECU or the drive ECU to be operated in an unauthorized manner, and therefore the abovementioned attack tool 500 has been added.
  • a plurality of sub-ECUs within the display ECU 380.
  • One of the sub-ECUs of the display ECU is a communication status ECU (not depicted), which displays the communication status by means of an indicator, an LED, or the like.
  • Figs. 28A and 28B depict an example in which a packet filter 510 is installed prior to the in-vehicle GW 310 as a countermeasure for the threat from the telematics device 340 and the OBD-II 350.
  • the packet filter 510 is installed as a result of the threat analysis tool unit 200 having analyzed a threat from the threat DB 240 with respect to the control model 110 and derived a countermeasure of inserting the packet filter 510. By then installing the packet filter 510, it is possible to block an unauthorized message from outside of the trust boundary.
  • the "ID” field is used to identify data content and a transmission node.
  • the "Data” field is used to transmit data of 0 to 8 bytes in 1-byte units.
  • the packet filter 510 is then able to determine whether to allow the CAN message to pass to the in-vehicle LAN or to block the CAN message, on the basis of the "ID" of the CAN message, namely the data content and the transmission node. That is, the packet filter 510, with respect to input from the telematics device 340 and the OBD-II 350, is able to pass only messages for legitimate ECUs such as the communication status ECU and block everything else, with the determination being made on the basis of the "ID". In this way, by installing the packet filter 510, the indicator or LED is able to correctly display a telematics communication status and a diagnostic device connection status, and unauthorized messages are blocked.
  • Fig. 30 is a diagram depicting a system development procedure according to a V-shaped model in embodiment 3.
  • a threat analysis is performed at an upstream stage of system development and the countermeasure list data 230 is output, and a countermeasure list indicated in the output countermeasure list data 230 is reflected in the control model 110.
  • the model-based development system 10 and the simulation function adding system 26 are made to cooperate, the attack list data 265 is output, and a function is added with which an attack on the control model 110 is simulated on the basis of an attack list indicated in the attack list data 265.
  • the software development system 1B in the present embodiment due to the model-based development system 10 and the threat analysis system 20B being made to cooperate, it is possible for a countermeasure for a new threat and a function that simulates an attack by that threat to be reflected in an executable control model at the system design stage, and it is therefore possible to confirm the effectiveness of a security countermeasure function upstream of the development stage. Therefore, it becomes possible to respond quickly with little refactoring.
  • a threat analysis it is possible for a threat analysis to be performed, a countermeasure for a threat to be output, and to have a function that performs a simulation to assess a model having the countermeasure reflected therein, in an upstream stage of system development according to a model-based development method, and it is therefore possible to reduce the refactoring of work in system development.
  • processing may be carried out by a processor or the like (described hereinafter) incorporated into a specific device arranged locally. Furthermore, processing may be carried out by a cloud server or the like arranged in a place different from that of a local device.
  • the granularity conversion unit 25 described in embodiments 1 to 3 is used to facilitate cooperation between the model-based development system and the threat analysis system, and therefore may be provided on a stand-alone basis.
  • a granularity conversion unit that has the control model created by a model-based development system input thereto, groups a plurality of elements making up the input control model in such a way that a predetermined granularity is implemented, and sets incoming/outgoing connections of a dataflow for the plurality of grouped elements to thereby output the plurality of grouped elements to the threat analysis tool unit as the individual elements of the control model.
  • the present disclosure may be realized by the computer program or the digital signal being transmitted via a network represented by an electric telecommunication line, a wireless or wired telecommunication line, and the Internet, or by a data broadcast or the like.
  • the present disclosure may be a computer system provided with a microprocessor and a memory, in which the memory stores the computer program and the microprocessor operates according to the computer program.
  • the present disclosure may be carried out by another independent computer system as a result of the program or the digital signal being recorded on the recording medium and transferred, or as a result of the program or the digital signal being transferred by way of the network or the like.
  • the present disclosure can be used in a software development system and a program, and, in particular, can be used in a software development system and a program for a device in which security is important such as the development of an integrated system such as an in-vehicle system.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Stored Programmes (AREA)
EP16189414.2A 2015-09-29 2016-09-19 Système de développement de logiciels dans un développement de systèmes basé sur une méthode basée sur un modèle Withdrawn EP3151114A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2015192242 2015-09-29
JP2016113938A JP2017068825A (ja) 2015-09-29 2016-06-07 ソフトウェア開発システムおよびプログラム

Publications (1)

Publication Number Publication Date
EP3151114A1 true EP3151114A1 (fr) 2017-04-05

Family

ID=57123787

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16189414.2A Withdrawn EP3151114A1 (fr) 2015-09-29 2016-09-19 Système de développement de logiciels dans un développement de systèmes basé sur une méthode basée sur un modèle

Country Status (2)

Country Link
US (1) US20170091462A1 (fr)
EP (1) EP3151114A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107357573A (zh) * 2017-06-26 2017-11-17 中交航局安装工程有限公司 一种煤炭港口运维业务数字化信息化的设计方法
EP3699798A1 (fr) * 2019-02-22 2020-08-26 Clarion Co., Ltd. Dispositif de support de planification de conception de sécurité

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10078500B2 (en) * 2016-09-23 2018-09-18 Dspace Digital Signal Processing And Control Engineering Gmbh Method and system for automatic code generation
US10867051B2 (en) * 2017-09-29 2020-12-15 AO Kaspersky Lab System and method of automated design of hardware and software systems and complexes
US10481906B2 (en) * 2017-10-25 2019-11-19 King Fahd University Of Petroleum And Minerals Refactoring to improve the security quality of use case models
US10740469B2 (en) * 2017-12-28 2020-08-11 Fmr Llc Automated secure software development management, risk assessment, and risk remediation
CN113056712A (zh) 2018-11-26 2021-06-29 Asml荷兰有限公司 用于确定半导体制造过程的事件的根源并且用于监测半导体制造过程的方法
JP7180500B2 (ja) * 2019-03-29 2022-11-30 オムロン株式会社 制御システム、および設定方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004280786A (ja) 2003-02-28 2004-10-07 Denso Corp 制御プログラムの検査方法及び検査装置及び検査プログラム
US20090083695A1 (en) * 2007-09-25 2009-03-26 Microsoft Corporation Enterprise Threat Analysis and Modeling
US20090327943A1 (en) * 2008-06-26 2009-12-31 Microsoft Corporation Identifying application program threats through structural analysis
US20120072968A1 (en) * 2007-02-16 2012-03-22 Wysopal Christopher J Assessment and analysis of software security flaws in virtual machines
JP2015041167A (ja) 2013-08-21 2015-03-02 日立オートモティブシステムズ株式会社 セキュリティ上の脅威を評価する評価装置及びその方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004280786A (ja) 2003-02-28 2004-10-07 Denso Corp 制御プログラムの検査方法及び検査装置及び検査プログラム
US20120072968A1 (en) * 2007-02-16 2012-03-22 Wysopal Christopher J Assessment and analysis of software security flaws in virtual machines
US20090083695A1 (en) * 2007-09-25 2009-03-26 Microsoft Corporation Enterprise Threat Analysis and Modeling
US20090327943A1 (en) * 2008-06-26 2009-12-31 Microsoft Corporation Identifying application program threats through structural analysis
JP2015041167A (ja) 2013-08-21 2015-03-02 日立オートモティブシステムズ株式会社 セキュリティ上の脅威を評価する評価装置及びその方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107357573A (zh) * 2017-06-26 2017-11-17 中交航局安装工程有限公司 一种煤炭港口运维业务数字化信息化的设计方法
EP3699798A1 (fr) * 2019-02-22 2020-08-26 Clarion Co., Ltd. Dispositif de support de planification de conception de sécurité
CN111614607A (zh) * 2019-02-22 2020-09-01 歌乐株式会社 安全设计制定辅助装置
US11381602B2 (en) 2019-02-22 2022-07-05 Hitachi, Ltd. Security design planning support device

Also Published As

Publication number Publication date
US20170091462A1 (en) 2017-03-30

Similar Documents

Publication Publication Date Title
EP3151114A1 (fr) Système de développement de logiciels dans un développement de systèmes basé sur une méthode basée sur un modèle
JP2017068825A (ja) ソフトウェア開発システムおよびプログラム
CN103930898B (zh) 程序分析/验证服务提供系统及其控制方法、程序分析/验证装置、程序分析/验证工具管理装置
EP3287927B1 (fr) Support d'enregistrement lisible par ordinateur non transitoire mémorisant un programme de support d'analyse de cyber-attaque, procédé et dispositif de support d'analyse de cyber-attaque
US8413237B2 (en) Methods of simulating vulnerability
US11531773B2 (en) Verification of bitstreams
JP6047463B2 (ja) セキュリティ上の脅威を評価する評価装置及びその方法
JP2007012003A (ja) フィーチャ指向ソフトウェア製品ラインの開発環境を提供するシステム
JP6361837B2 (ja) 訓練装置、訓練方法、及び訓練プログラム
EP3432229A1 (fr) Dispositif de génération de données de communication de capacité
CN102667867A (zh) 改进的计算机实施的几何特征检测方法
JP2012181666A (ja) 情報処理装置、情報処理方法及び情報処理プログラム
JP5718166B2 (ja) 設計検証方法及びプログラム
WO2019142469A1 (fr) Appareil de conception de sécurité, procédé de conception de sécurité et programme de conception de sécurité
CN113609823B (zh) 问卷逻辑的编辑方法、装置、终端设备及存储介质
US20080195453A1 (en) Organisational Representational System
JP6274090B2 (ja) 脅威分析装置、及び脅威分析方法
US9338294B2 (en) Automated task definitions
JP7220095B2 (ja) セキュリティ設計立案支援装置
KR101829426B1 (ko) 문자열 점수 기반 소프트웨어 저장 장치와 분류 장치 및 그 방법
JP2007310727A (ja) 資産診断のためのプログラム解析方法
WO2017085921A1 (fr) Système, procédé et programme d'analyse de journal
US20230274005A1 (en) Information processing apparatus, and computer program product
JP2009205239A (ja) ソフトウェア検証システム
CN110765327A (zh) 数据分析方法、装置、计算机装置及存储介质

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20171006