KR102476360B1 - Requirements analysis and design methodology for system - Google Patents

Abstract

In the method for deriving and designing system requirements using a processor of a computing device according to some embodiments of the present disclosure, deriving requirements for safety and security of a design target system; Based on the requirements, designing the design target system; and determining whether the design target system satisfies the requirements.

Description

System requirements derivation and design method {REQUIREMENTS ANALYSIS AND DESIGN METHODOLOGY FOR SYSTEM}

The present disclosure relates to a method for deriving and designing requirements in the development process of a high-reliability system through security and safety synthesis, and existing security analysis evaluation activities and safety in the requirements derivation and design stages of system development. It is about a method of deriving and designing system requirements integrating analysis and evaluation activities. Specifically, the present disclosure provides an integrated evaluation of security and safety, which has been considered through different activities, by preventing conflicts between requirements, and a system requirement derivation and design method that can be utilized when developing a system requiring high reliability. it's about

Research on this disclosure is the result of a study supported by the Ministry of Science and ICT in 2020.

The task name related to this disclosure is 'IoT security technology research', and the task identification number is '1711103082'.

As the number of components such as ECUs, modules, and sensors mounted in vehicles increases and IoT-related technologies are advanced, various IoTs provided through third parties are being installed in vehicles. However, according to the papers "Comprehensive Experimental Analyzes of Automotive Attack Surfaces" published in Usenix in 2011 and "A Survey of Remote Automotive Attack Surfaces" published in BlackHat USA in 2014, the attack surface for vehicles is increasing due to the above reasons. , This means that the possibility of security threats occurring through the corresponding attack surfaces also increases. For this reason, the vehicle cyber security market is continuously increasing, and according to Grand View Research, a market size research institute, in the case of the United States, referring to FIG. projected to rise to billions of dollars.

Therefore, for the reasons described above, there is a need to evaluate products in consideration of security and thereby reduce the possibility of security threats. Security is a concept including confidentiality, integrity, and availability, and it is intended to prevent a situation in which external security threats expand into the system and cause harm to users. If security is not guaranteed, it may lead to various accidents such as leakage of privacy or internal confidential information by an external user without authorization authority for the system or intentional malfunction causing system problems. Confidentiality may mean ensuring that only authorized users can access information assets of the system. Integrity may mean ensuring that the system is fully preserved without inappropriate information being altered or destroyed. Availability may mean always ensuring access to and use of system information.

However, not only vehicles, but also complex embedded-based systems requiring high reliability, such as cyber physical systems (CPS), have been developed mainly in consideration of the level of functional safety that products should have. Functional safety is a concept that includes accuracy and safety, and is intended to prevent a situation in which malfunctions occurring within the electric-electronic system are exposed to the outside and cause injury to users. If functional safety is not guaranteed, errors occur in simple system operation and It can lead not only to the same problems, but also to problems directly related to life, such as human casualties. Accuracy can mean ensuring that a product behaves exactly as designed. Safety may mean guaranteeing that an error generated inside a product cannot be exposed to the outside and cause damage to a user. For this reason, there is a need to evaluate security in order to prepare for threats in addition to considering only the existing functional safety for high-reliability systems, and there is a need to design products by considering both security and safety from the design stage when developing products.

ISO 26262, J3061, Common Criteria, IEC 61508, etc. may exist as standards that can be evaluated in consideration of security and safety for the developed high-reliability system. ISO 26262 may mean a standard that must be followed to ensure the safety of vehicles in each detailed development stage in the V-model of the software development life cycle model. Similar to ISO 26262, SAE J3061 can mean a standard that must be followed to secure vehicle security in each detailed development stage of the V-model. The Common Criteria can mean a standard that can evaluate the security of security activities and products in the detailed development stage of IT products equipped with security functions through the Common Criteria Methodology. IEC 61508 is a standard that specifies functional safety for electrical/electronic/programmable electronic systems, and covers the entire process from the concept stage of the system through the safety life cycle (SIL, Safety Integrity Level) to implementation, mass production, management, and disposal. may mean a standard that presents

Companies and institutions can develop a highly reliable system that secures safety and security in the development stage by complying with the above standards. However, since these are different standards, conflicts between security and safety functions within the SAE J3061 standard impede the assurance level of the evaluation target, or it takes a long time to develop vehicles by applying both standards. exist.

Therefore, it is necessary to prevent conflicts between requirements and establish a synthetic evaluation process by integrating evaluation activities within the system design stage described in security-related standards and safety-related standards.

Republic of Korea Patent Publication No. 10-2002-0056656

The present disclosure has been made in response to the above background art, and is intended to provide a system requirement derivation and design method.

Specifically, in the development stage for high-reliability systems such as existing vehicles and cyber physical systems (CPS, Cyber Physical System), they were designed only in consideration of functional safety, including the concepts of accuracy and safety, but the number of components installed in the system is increasing and As electronic technology has increased, the types of attack surfaces and the number of security threats that can exist accordingly have increased, and as a result, the possibility of hacking cases such as privacy and internal information leakage has increased.

Therefore, since functional safety and security are properties that must be satisfied at the same time in a high-reliability system, both must be considered in the development stage. The problem exists that the requirements derived for each sex may conflict with each other.

In order to solve these problems, activities for the derivation and design stages of development within the functional safety and security target standards are synthesized, and the designed module satisfies the traceability with the requirements derived in the requirements derivation stage. The purpose of this study is to provide a way to design a highly reliable system that satisfies functional safety and security by presenting a methodology with added steps.

The technical problems of the present disclosure are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art from the following description.

A method for deriving and designing system requirements using a processor of a computing device to solve the above problems, comprising: deriving requirements for safety and security of a system to be designed; Based on the requirements, designing the design target system; and determining whether the design target system satisfies the requirements.

In addition, the step of deriving the requirements for satisfying the safety and security of the system to be designed includes identifying components of the system to be designed and generating a data flow diagram based on the components. ; generating a problem library related to vulnerabilities of the design target system and attack methods for the design target system, based on a plurality of data; Recognizing expected problems that may occur in the design target system based on preset safety and security attributes; generating a problem tree based on an identification problem generated by applying the predicted problem to the data flow chart and the problem library; deriving a degree of risk for the identification problem based on the problem tree; And based on the degree of risk, deriving the requirements; may include.

In addition, in the step of designing the target system based on the requirements, the subsystem of the target system is identified based on a preset standard identification method, and each of the plurality of modules is identified based on the subsystem. identifying a unit and identifying a parameter used in each of the plurality of modules based on the plurality of modules; setting a safety range of each of the subsystem, the plurality of modules, and the parameter based on preset safety information; identifying a correlation between the plurality of modules based on a call graph representing a call relationship between the plurality of modules; verifying the safety range based on preset safety information, determining a complexity of each of the plurality of modules based on a correlation between the plurality of modules, and simplifying each of the plurality of modules; verifying the problem library based on the plurality of materials, and deriving a probability value of the identification problem according to a preset standard; verifying the data flow chart based on a preset creation criterion; and determining whether the minimum complexity of each of the plurality of modules is satisfied using a program design language.

In addition, based on the risk level, the step of deriving the requirements may include determining an importance level for the identification problem based on the risk level; determining, based on the degree of importance, whether the requirement for solving the identification problem is implemented; and deriving the requirements when the requirements are implemented.

In addition, the step of deriving the degree of risk for the identification problem based on the problem tree includes damage possibility information, which is a degree of damage when the identification problem occurs, reproducibility information, which is a difficulty for reproducing the identification problem, and the identification problem. A score is set based on exploitability information, which is the need for knowledge to generate a problem, user information, which is the number of users affected when the identification problem occurs, and discoverability information, which is a difficulty for discovering the identification problem, and the risk level Deriving; may include.

In addition, the step of determining whether the minimum complexity of each of the plurality of modules is satisfied using the program design language is to check whether the minimum complexity is satisfied using pseudocode or source code in a predetermined complexity measurement algorithm. step; may be included.

In addition, the data flow chart may include information on each of a plurality of functions provided by the design target system and information on data transmitted and received between the plurality of functions.

In addition, the problem tree includes information on a final attack target, the final attack target is disposed at a top node of the problem tree, and at least one target related to the final attack target is placed at at least one lower node associated with the top node. Problems can be placed.

The technical solutions obtainable in the present disclosure are not limited to the above-mentioned solutions, and other solutions not mentioned will become clear to those skilled in the art from the description below. You will be able to understand.

When a system requiring high reliability is developed, the present disclosure can satisfy functional safety and security, which must be satisfied by the finally developed system.

In addition, since the present disclosure synthesizes the activities of the derivation of requirements and design stages defined in the existing functional safety-related standards and security-related standards, the design for functional safety and the design for security are separated. Since it is not performed, it is possible to prevent conflicts between safety and security requirements while reducing cost and time consumed in the design stage.

Effects obtainable in the present disclosure are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the description below. .

Various aspects are now described with reference to the drawings, wherein like reference numbers are used to collectively refer to like elements. In the following embodiments, for explanation purposes, numerous specific details are set forth in order to provide a thorough understanding of one or more aspects. However, it will be apparent that such aspect(s) may be practiced without these specific details.
1 is a graph of vehicle cyber security market size.
2 is a diagram schematically illustrating a process of developing, operating, maintaining, and discarding a conventional system.
3 is a diagram illustrating a conventional system requirement derivation process.
4 is a diagram showing a conventional system design process.
5 is a block diagram of a computing device for performing system requirements derivation and design according to some embodiments of the present disclosure.
6 to 9 are flowcharts illustrating a system requirement derivation and design method according to some embodiments of the present disclosure.
10 is a diagram for explaining an example of a data flow diagram according to some embodiments of the present disclosure.
11 is a diagram for explaining an example of a problem tree according to some embodiments of the present disclosure.
12 is a general schematic diagram of an example computing environment in which embodiments of the present disclosure may be implemented.

Various embodiments and/or aspects are now disclosed with reference to the drawings. In the following description, for purposes of explanation, numerous specific details are set forth in order to facilitate a general understanding of one or more aspects. However, it will also be appreciated by those skilled in the art that such aspect(s) may be practiced without these specific details. The following description and accompanying drawings describe in detail certain illustrative aspects of one or more aspects. However, these aspects are exemplary and some of the various methods in principle of the various aspects may be used, and the described descriptions are intended to include all such aspects and their equivalents. Specifically, “embodiment,” “example,” “aspect,” “exemplary,” etc., as used herein, is not to be construed as indicating that any aspect or design described is superior to or advantageous over other aspects or designs. Maybe not.

Hereinafter, the same reference numerals are given to the same or similar components regardless of reference numerals, and overlapping descriptions thereof will be omitted. In addition, in describing the embodiments disclosed in this specification, if it is determined that a detailed description of a related known technology may obscure the gist of the embodiment disclosed in this specification, the detailed description thereof will be omitted. In addition, the accompanying drawings are only for easy understanding of the embodiments disclosed in this specification, and the technical ideas disclosed in this specification are not limited by the accompanying drawings.

Unless otherwise defined, all terms (including technical and scientific terms) used in this specification may be used in a meaning commonly understood by those of ordinary skill in the art to which this disclosure belongs. In addition, terms defined in commonly used dictionaries are not interpreted ideally or excessively unless explicitly specifically defined.

Additionally, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless otherwise specified or clear from the context, “X employs A or B” is intended to mean one of the natural inclusive substitutions. That is, X uses A; X uses B; Or, if X uses both A and B, "X uses either A or B" may apply to either of these cases. Also, the term “and/or” as used herein should be understood to refer to and include all possible combinations of one or more of the listed related items.

Also, the terms "comprises" and/or "comprising" mean that the feature and/or element is present, but excludes the presence or addition of one or more other features, elements and/or groups thereof. It should be understood that it does not. Also, unless otherwise specified or where the context clearly indicates that a singular form is indicated, the singular in this specification and claims should generally be construed to mean "one or more".

In addition, the term “at least one of A or B” should be interpreted as meaning “when only A is included”, “when only B is included”, and “when A and B are combined”.

It is understood that when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, but other elements may exist in the middle. It should be. On the other hand, when a component is referred to as “directly connected” or “directly connected” to another component, it should be understood that no other component exists in the middle.

The suffixes "module" and "unit" for components used in the following description are given or used interchangeably in consideration of ease of writing the specification, and do not have meanings or roles that are distinct from each other by themselves.

Objects and effects of the present disclosure, and technical configurations for achieving them will become clear with reference to embodiments described later in detail in conjunction with the accompanying drawings. In describing the present disclosure, if it is determined that a detailed description of a known function or configuration may unnecessarily obscure the gist of the present disclosure, the detailed description will be omitted. In addition, terms to be described below are terms defined in consideration of functions in the present disclosure, which may vary according to the intention or custom of a user or operator.

However, the present disclosure is not limited to the embodiments disclosed below and may be implemented in a variety of different forms. These embodiments are provided only to make this disclosure complete and to completely inform those skilled in the art of the scope of the disclosure, and the disclosure is only defined by the scope of the claims. . Therefore, the definition should be made based on the contents throughout this specification.

A method of deriving and designing system requirements according to some embodiments of the present disclosure may refer to a method of simultaneously performing analysis and evaluation of security and safety in a system requirement derivation step and a system design step. Here, analysis and evaluation of security may refer to an evaluation conducted to prevent a situation in which an external security threat expands into a system and causes damage to a user. In addition, analysis and evaluation of safety may refer to an evaluation conducted to prevent a situation in which a malfunction occurring in the system is exposed to the outside and causes injury to a user.

2 is a diagram schematically illustrating a conventional system development, operation, maintenance, and disposal process. 3 is a diagram illustrating a conventional system requirement derivation process. 4 is a diagram showing a conventional system design process.

Referring to FIG. 2 , in the conventional system development step, safety requirements and security requirements were derived respectively in the step of deriving system requirements. Specifically, referring to FIG. 3 , the conventional safety requirements were derived by identifying system components based on a safety analysis and evaluation method, analyzing possible failure causes for each component, and performing risk evaluation. Here, the safety analysis evaluation method could include preliminary hazard analysis (PHA). In addition, the conventional security requirements were derived by drawing a data flow diagram based on a security analysis evaluation method, building an attack library, identifying threats, creating an attack tree, and performing risk assessment. Here, the security analysis evaluation method may include threat modeling.

As described above, system requirements were derived including safety requirements and security requirements, respectively derived. Since the step of deriving the above-described conventional system requirements derives safety requirements and security requirements, respectively, conflicts may occur due to conflicting requirements.

Referring back to FIG. 2, in the step of designing the system, each function is designed based on the safety and security requirements, each function is implemented, and the implemented safety and security functions are combined to complete the system design. .

Specifically, referring to FIG. 4 , after identifying subsystems based on system requirements, identifying modules of subsystems, and identifying parameters for each module, system design is based on safety requirements regarding safety. Functions were implemented, and security-related functions were implemented based on security requirements. Here, the evaluation of safety-related functions may include methods such as hazard and operability analysis and fault tree analysis (FTA). In addition, the evaluation of security-related functions could include evaluation of the design of the evaluation target system (ADV_TDS) and the inside of the evaluation target system's security function (ADV_INT) among the components within the Common Criteria.

And, in the system design stage, it was confirmed whether the traceability of safety-related functions and security-related functions, that is, whether the safety-related functions and security-related functions were properly reflected. And, in the system design stage, the system design was completed when the reflection was correct, and the stage of deriving system requirements when the reflection was not correct was reevaluated. Since the above-described conventional system design step derives a function related to safety and a function related to security, respectively, a conflict may occur due to conflicting functions of each other.

Referring back to FIG. 2, after the system design stage, if the safety and security of the designed system are verified and tested, operation and maintenance of the designed system is performed, and the designed system is discarded. It was possible to perform the discard for the system designed in .

In the process of development, operation, maintenance, and disposal of the conventional systems described above in FIGS. 2 to 4, requirements were derived by separating safety and security, and functions were designed and implemented based on each requirement. Therefore, in the conventional system development, operation, maintenance, and disposal process, functions related to safety and security may conflict and conflicts may occur, and it takes a long time to develop the system, and development costs increase as time increases. there was

Meanwhile, the computing device 100 according to some embodiments of the present disclosure simultaneously performs analysis and evaluation on safety and security in the system requirements derivation phase and the system design phase, so that functions related to safety and security conflict and conflict occurs. prevent this from happening and reduce the time to develop the system. A detailed description of this will be described later with reference to FIG. 5 .

5 is a block diagram of a computing device for performing system requirements derivation and design according to some embodiments of the present disclosure.

Referring to FIG. 5 , the computing device 100 may include a processor 110 , a communication unit 120 and a memory 130 . However, since the above-described components are not essential to implement the computing device 100, the computing device 100 may have more or fewer components than the components listed above.

Computing device 100 may include any type of computer system or computer device, such as, for example, microprocessors, mainframe computers, digital processors, portable devices and device controllers, and the like. However, it is not limited thereto.

The processor 110 of the computing device 100 typically controls the overall operation of the computing device 100 . The processor 110 provides appropriate information or functions to the user by processing signals, data, information, etc. input or output through components included in the computing device 100 or by running an application program stored in the memory 130. or can be processed.

Also, the processor 110 may control at least some of the components of the computing device 100 in order to drive an application program stored in the memory 130 . Furthermore, the processor 110 may combine and operate at least two or more of the components included in the computing device 100 to drive the application program.

The communication unit 120 of the computing device 100 may include one or more modules enabling communication between the computing device 100 and a user terminal and between the computing device 100 and external servers. Also, the communication unit 120 may include one or more modules that connect the computing device 100 to one or more networks.

Networks connecting communication between the computing device 100 and user terminals and between the computing device 100 and external servers include a public switched telephone network (PSTN), x digital subscriber line (xDSL), and rate rate RADSL (RADSL). Adaptive DSL), MDSL (Multi Rate DSL), VDSL (Very High Speed DSL), UADSL (Universal Asymmetric DSL), HDSL (High Bit Rate DSL), and various wired communication systems such as local area network (LAN) can be used.

In addition, the network presented here is CDMA (Code Division Multi Access), TDMA (Time Division Multi Access), FDMA (Frequency Division Multi Access), OFDMA (Orthogonal Frequency Division Multi Access), SC-FDMA (Single Carrier-FDMA) and Various wireless communication systems may be used, such as different systems.

The network according to the embodiments of the present disclosure may be configured regardless of its communication mode, such as wired and wireless, and is composed of various communication networks such as a local area network (LAN) and a wide area network (WAN). It can be. In addition, the network may be the known World Wide Web (WWW), or may use a wireless transmission technology used for short-range communication, such as Infrared Data Association (IrDA) or Bluetooth.

The techniques described herein may be used in the networks mentioned above as well as other networks.

The memory 130 of the computing device 100 may store programs for operation of the processor 110 and may temporarily or permanently store input/output data. The memory 130 may be a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (eg SD or XD memory, etc.), RAM (Random Access Memory, RAM), SRAM (Static Random Access Memory), ROM (Read-Only Memory, ROM), EEPROM (Electrically Erasable Programmable Read-Only Memory), PROM (Programmable Read-Only Memory), magnetic memory, magnetic It may include at least one type of storage medium among disks and optical disks. This memory 130 may be operated under the control of the processor 110 .

According to software implementation, embodiments such as procedures and functions described in this specification may be implemented as separate software modules. Each of the software modules may perform one or more functions and operations described herein. The software code may be implemented as a software application written in any suitable programming language. The software code may be stored in the memory 130 of the computing device 100 and executed by the processor 110 of the computing device 100 .

The processor 110 of the computing device 100 according to some embodiments of the present disclosure may perform operations related to deriving system requirements and designing a system. A detailed description of this will be described later in detail with reference to FIGS. 6 to 11 .

6 to 9 are flowcharts illustrating a system requirement derivation and design method according to some embodiments of the present disclosure. 10 is a diagram for explaining an example of a data flow diagram according to some embodiments of the present disclosure. 11 is a diagram for explaining an example of a problem tree according to some embodiments of the present disclosure.

Referring to FIG. 6 , the processor 110 of the computing device 100 of the present disclosure may derive requirements for safety and security of the design target system (S100).

Here, safety may mean guaranteeing that an error generated inside the product cannot be exposed to the outside and cause damage to the user. Also, safety may be a concept including accuracy. Here, accuracy may mean ensuring that a product operates exactly as designed. However, it is not limited thereto.

Meanwhile, security may be a concept including confidentiality, integrity, and availability. Confidentiality may mean ensuring that only authorized users can access information assets of the system. Integrity may mean ensuring that the system is fully preserved without inappropriate information being altered or destroyed. Availability may mean always ensuring access to and use of system information. However, it is not limited thereto.

Specifically, referring to FIG. 7 , the processor 110 may identify components of the system to be designed and generate a data flowchart based on the components (S110).

Here, the components may include at least one hardware or at least one software function element constituting the design target system. However, it is not limited thereto.

Meanwhile, the data flow chart may include information on each of a plurality of functions provided in the design target system and information on data transmitted and received between the plurality of functions. However, it is not limited thereto.

Specifically, referring to FIG. 10 , an example of a data flow diagram created by the processor 110 of the computing device 100 is shown.

The data flow diagram 400 may include information 402 on a plurality of functions and information 403 on data transmitted and received between a plurality of functions, centering on the system to be designed 401 .

For example, when the design target system 401 is a '5G security function interface', information 402 on a plurality of functions includes information on 'key management', information on 'authentication', and 'encryption/decryption'. ' may be included. In addition, information 403 on data transmitted and received between a plurality of functions includes information on 'key management', information on 'requested key', which is data transmitted and received between '5G security function interface', and 'network key' may contain information about However, it is not limited thereto.

Referring back to FIG. 7 , the processor 110 may generate a problem library related to vulnerabilities of the design target system and attack methods for the design target system based on a plurality of data (S120).

Here, the plurality of data may include data collected through at least one of papers, conferences, technical documents, Common Vulnerabilities and Exposures (CVE), and Common Weakness Enumeration (CWE).

In addition, the vulnerability of the design target system may mean an element that threatens the safety and security of the design target system. That is, the processor 110 based on a plurality of data. It is possible to create a problem library related to elements that threaten the stability and security of the design target system and attack methods for the design target system.

Meanwhile, the processor 110 may recognize expected problems that may occur in the design target system based on preset safety and security attributes (S130).

Here, the preset safety attributes may include a Preliminary Hazard Analysis (PHA). In addition, the preset security attributes may include spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege (STRIDE). However, it is not limited thereto.

Meanwhile, the processor 110 may generate a problem tree based on an identified problem generated by applying an expected problem to a data flow diagram and a problem library (S140).

Here, the problem tree may include information about a final attack target. In addition, a final attack target may be arranged at the top node of the problem tree, and at least one threat related to the final attack target may be arranged at at least one lower node associated with the top node. However, it is not limited thereto.

Specifically, referring to FIG. 11 , an example of a problem tree created by the processor 110 of the computing device 100 is shown.

Here, in the problem tree 500, the final attack target may be placed at the top node 501. For example, the final attack target included in the top node 501 may be 'System Destruction'. However, it is not limited thereto.

In addition, at least one threat related to a final attack target may be disposed at a lower node 502 of the problem tree 500 . For example, at least one threat included in the lower node 502 may include 'System Access' and 'Rootkits Installation'. However, it is not limited thereto.

Referring back to FIG. 7 , the processor 110 may derive a risk level for the identification problem based on the problem tree (S150).

Here, the processor 110 sets a score based on damage potential information, reproducibility information, exploitability information, affected users information, and discoverability information, and determines a risk level. can be derived Here, the degree of risk may be a quantitative representation of the degree to which the identification problem is dangerous or the degree to which the risk is likely to occur due to the identification problem.

Meanwhile, the damage possibility information may include information representing the degree of damage when an identification problem occurs. More specifically, when an identification problem occurs, the processor 110 may set a score based on the degree of damage caused by the identification problem and derive a degree of risk.

In addition, the reproducibility information may include information indicating a level of difficulty for reproducing the identification problem. Specifically, the processor 110 may set a score based on difficulty for reproducing the identification problem and derive a degree of risk.

Additionally, the exploitability information may include information indicating the need for knowledge to generate an identification problem. Specifically, the processor 110 may set a score and derive a degree of risk based on the need for knowledge to generate an identification problem.

Also, the user information may include information about the number of users affected when an identification problem occurs. Specifically, the processor 110 may set a score based on the number of affected users when an identification problem occurs and derive a risk level.

Also, the discoverability information may include information about difficulty for discovering an identification problem. Specifically, the processor 110 may set a score and derive a degree of risk based on the level of difficulty for discovering the identification problem.

On the other hand, the processor 110 may derive a requirement based on the degree of risk (S160).

Specifically, referring to FIG. 8 , the processor 110 may determine the importance of the identification problem based on the degree of risk (S161).

Here, the importance level indicates the degree of consideration of the identification problem, and can be represented by the first level when the level of importance is low, the second level when the level of importance is normal, and the third level when the level of importance is high. For example, if the processor 110 determines that the identification problem will cause a great problem to the system, the processor 110 may determine the importance of the identification problem as a third step. That is, the processor 110 may determine a step indicating the degree of consideration of the identification problem based on the degree of risk.

More specifically, the processor 110 may determine the importance based on preset conditions. Here, the preset conditions may represent conditions for risk. For example, the processor 110 sets preset conditions to a condition with a risk of 0 to 40 (more than 0 and less than 40), a condition with a risk of 40 to 80 (more than 40 and less than 80), and a condition with a risk of 80 to 100 (more than 80 and less than 100). Less than) can be set as a condition. Here, the processor 110 determines the importance as the first step when the risk corresponds to the condition of 0 to 40, and determines the importance as the second step when the risk corresponds to the condition of 40 to 80, and the risk In case that corresponds to the condition of 80 to 100, the importance can be determined as the third step. However, it is not limited thereto.

Meanwhile, the processor 110 may determine whether to implement a requirement for solving the identification problem based on the importance (S162).

For example, the processor 110 may determine that the requirements for solving the identification problem are not implemented when the importance of the identification problem is determined as the first or second level (ie, a level with a low risk). . For another example, the processor 110 may determine that the requirements for solving the identification problem are implemented when the importance of the identification problem is determined to be the third level (ie, the high risk level).

Meanwhile, when the processor 110 implements the requirements, it may derive the requirements (S163).

For example, when it is determined that the requirements for solving the identification problem in the third step are implemented, the processor 110 recognizes the identification problem determined in the third step, and the processor 110 recognizes the identification problem determined in the third step. requirements can be derived.

As in some embodiments described above with reference to FIGS. 7 and 8 , the processor 110 may simultaneously derive requirements for safety and security of the system to be designed in the step of deriving requirements for the system to be designed.

Referring back to FIG. 6 , the processor 110 may design a design target system based on requirements (S200).

Specifically, referring to FIG. 9 , the processor 110 may identify a subsystem, a plurality of modules, and parameters (S210).

More specifically, the processor 110 may identify the subsystem of the design target system based on a preset standard identification method. Also, the processor 110 may identify each unit of a plurality of modules based on the subsystem. Also, the processor 110 may identify parameters used in each of the plurality of modules based on the plurality of modules. Here, the parameter may mean a function interface in the source code. However, it is not limited thereto.

Meanwhile, the processor 110 may set safety ranges of each subsystem, a plurality of modules, and parameters based on preset safety information (S220).

Here, the safety range may be a range related to a delay time for each subsystem, a plurality of modules, and parameters to be guaranteed. For example, a low delay time may be set for a component requiring high safety, and a high delay time may be set for a component requiring low safety. However, it is not limited thereto. Here, the delay time may mean a time from when a specific signal is input to output. That is, the processor 110 may set a range related to a delay time to be guaranteed for each subsystem, a plurality of modules, and parameters based on preset safety information.

Here, the preset safety information may be safety-related information for each of a plurality of subsystems, a plurality of modules, and a plurality of parameters. That is, the processor 110 may set the safety range of each of the subsystem to be designed, the plurality of modules, and the parameters based on the information on the safety of each of the plurality of subsystems, the plurality of modules, and the plurality of parameters.

Meanwhile, the processor 110 may identify a correlation between a plurality of modules based on a call graph representing a call relationship between a plurality of modules (S230).

Here, the call graph may represent a call relationship between a plurality of modules in a tree form. That is, the processor 110 may identify a correlation between a plurality of modules based on a call graph representing a call relationship between a plurality of modules in a tree form.

Meanwhile, the processor 110 may verify the safety range based on preset safety information, determine the complexity of each of the plurality of modules based on the correlation between the plurality of modules, and simplify each of the plurality of modules ( S240).

Specifically, the processor 110 may determine whether the safety range is correctly set based on preset safety information. Here, the processor 110 may perform the previous steps S220 and S230 again when recognizing that the safety range is not correctly set.

Also, the processor 110 may determine whether to simplify each of the plurality of modules according to complexity. For example, the processor 110 may not perform simplification when the complexity is less than a preset value, and may perform simplification when the complexity is greater than the preset value.

Meanwhile, the processor 110 may verify a problem library based on a plurality of data and derive a probability value of an identification problem according to a predetermined criterion (S250).

Specifically, the processor 110 may determine whether or not the problem library is correctly written based on a plurality of data. Here, the processor 110 may perform the previous step (S100) again when recognizing that the problem library is not created correctly.

Here, the probability value of the identification problem may be a value predicted in which scenario the identification problem will occur based on the problem library. That is, the processor 110 may verify a problem library based on a plurality of data and derive a value predicting a scenario in which an identification problem will occur based on the problem library according to a predetermined criterion. Here, the preset criterion may be an occurrence probability value set according to a plurality of identification problems and a plurality of scenarios. However, it is not limited thereto.

On the other hand, the processor 110 may verify the data flow diagram based on a preset writing criterion (S260).

Specifically, the processor 110 may verify whether the parameters written in the data flow chart are written correctly based on a preset writing criterion.

Meanwhile, the processor 110 may determine whether the minimum complexity of each of a plurality of modules is satisfied by using a program design language (S270).

Specifically, the processor 110 may check whether the minimum complexity is satisfied by using a pseudocode or source code for a predetermined complexity measurement algorithm.

Here, the predetermined complexity measurement algorithm may include at least one of McCabe and Halstead. That is, the processor 110 may check whether the minimum complexity is satisfied by using pseudo code or source code for at least one of McCabe and Halstead. However, it is not limited thereto.

Meanwhile, the processor 110 may perform the next step (S300) when the minimum complexity of each of the plurality of modules is satisfied.

According to some embodiments of the present disclosure, when the minimum complexity of each of the plurality of modules is not satisfied, the processor 110 repeats the previous steps (S240 to S260) to re-determine whether the minimum complexity of each of the plurality of modules is satisfied. can do.

Meanwhile, the preceding steps (S240 to S260) may be performed in parallel rather than sequentially.

As in some embodiments described above with reference to FIG. 9 , the processor 110 may design a design target system based on requirements for safety and security of the design target system.

Referring back to FIG. 6 , the processor 110 may determine whether the design target system satisfies requirements (S300).

Here, the processor 110 may determine that the design target system is completed when the design target system satisfies the requirements.

According to some embodiments of the present disclosure, when the design target system does not satisfy the requirements, the processor 110 may perform the above-described step S200 again and re-determine whether the requirements are satisfied.

According to some other embodiments of the present disclosure, if the design target system does not satisfy the requirements, the processor 110 may perform the above-described steps (S100 and S200) again and re-determine whether the requirements are satisfied. have. However, it is not limited thereto.

As in some embodiments described above with reference to FIG. 6 , the processor 110 derives requirements for the safety and security of the system to be designed, and designs the system to be designed based on the requirements, so that functions related to safety and security are provided. Conflicts can be prevented from occurring and the time to develop the system can be reduced.

The steps shown in FIGS. 6 to 9 are exemplary steps, and it will also be apparent to those skilled in the art that some of the steps in FIGS. 6 to 9 may be omitted or additional steps may be present without departing from the scope of the present disclosure. will be. 6 to 9 (eg, the processor 110, the communication unit 120, and the memory 130 of the computing device 100) are replaced with those described above with reference to FIG. 5. It can be.

12 is a general schematic diagram of an example computing environment in which embodiments of the present disclosure may be implemented.

Although the present disclosure has generally been described above in terms of computer-executable instructions that can be executed on one or more computers, those skilled in the art will understand that the present disclosure may be understood in combination with computer-executable instructions and/or other program modules that can be executed on one or more computers, and It will be appreciated that/or may be implemented as a combination of hardware and software.

Generally, program modules include routines, programs, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In addition, those skilled in the art will understand that the methods of the present disclosure can be applied to single-processor or multiprocessor computer systems, minicomputers, mainframe computers as well as personal computers, handheld computing devices, microprocessor-based or programmable consumer electronics, and the like ( It will be appreciated that each of these may be implemented with other computer system configurations, including those that may be operative in connection with one or more associated devices.

The described embodiments of the present disclosure may also be practiced in distributed computing environments where certain tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

Computers typically include a variety of computer readable media. Computer readable media can be any medium that can be accessed by a computer, including volatile and nonvolatile media, transitory and non-transitory media, removable and non-transitory media. Includes removable media. By way of example, and not limitation, computer readable media may include computer readable storage media and computer readable transmission media. Computer readable storage media are volatile and nonvolatile media, transitory and non-transitory, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. includes media Computer readable storage media may include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital video disk (DVD) or other optical disk storage device, magnetic cassette, magnetic tape, magnetic disk storage device or other magnetic storage device. device, or any other medium that can be accessed by a computer and used to store desired information.

A computer readable transmission medium typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism. Including all information delivery media. The term modulated data signal means a signal that has one or more of its characteristics set or changed so as to encode information within the signal. By way of example, and not limitation, computer readable transmission media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above are also intended to be included within the scope of computer readable transmission media.

An exemplary environment 1100 implementing various aspects of the present disclosure is shown including a computer 1102, which includes a processing unit 1104, a system memory 1106, and a system bus 1108. do. System bus 1108 couples system components, including but not limited to system memory 1106 , to processing unit 1104 . Processing unit 1104 may be any of a variety of commercially available processors. Dual processor and other multiprocessor architectures may also be used as the processing unit 1104.

System bus 1108 may be any of several types of bus structures that may additionally be interconnected to a memory bus, a peripheral bus, and a local bus using any of a variety of commercial bus architectures. System memory 1106 includes read only memory (ROM) 1110 and random access memory (RAM) 1112 . A basic input/output system (BIOS) is stored in non-volatile memory 1110, such as ROM, EPROM, or EEPROM, and is a basic set of information that helps transfer information between components within computer 1102, such as during startup. contains routines. RAM 1112 may also include high-speed RAM, such as static RAM, for caching data.

The computer 1102 may also include an internal hard disk drive (HDD) 1114 (eg, EIDE, SATA) - the internal hard disk drive 1114 may also be configured for external use within a suitable chassis (not shown). Yes—a magnetic floppy disk drive (FDD) 1116 (e.g., for reading from or writing to a removable diskette 1118), and an optical disk drive 1120 (e.g., a CD-ROM) for reading disc 1122 or reading from or writing to other high capacity optical media such as DVDs). The hard disk drive 1114, magnetic disk drive 1116, and optical disk drive 1120 are connected to the system bus 1108 by a hard disk drive interface 1124, magnetic disk drive interface 1126, and optical drive interface 1128, respectively. ) can be connected to The interface 1124 for external drive implementation includes at least one or both of USB (Universal Serial Bus) and IEEE 1394 interface technologies.

These drives and their associated computer readable media provide non-volatile storage of data, data structures, computer executable instructions, and the like. In the case of computer 1102, drives and media correspond to storing any data in a suitable digital format. Although the description of computer readable media above refers to HDDs, removable magnetic disks, and removable optical media such as CDs or DVDs, those skilled in the art can use zip drives, magnetic cassettes, flash memory cards, cartridges, etc. It will be appreciated that other tangible media readable by the computer, such as the like, may also be used in the exemplary operating environment and any such media may include computer executable instructions for performing the methods of the present disclosure.

A number of program modules may be stored on the drive and RAM 1112, including an operating system 1130, one or more application programs 1132, other program modules 1134, and program data 1136. All or portions of the operating system, applications, modules and/or data may also be cached in RAM 1112. It will be appreciated that the present disclosure may be implemented in a variety of commercially available operating systems or combinations of operating systems.

A user may enter commands and information into the computer 1102 through one or more wired/wireless input devices, such as a keyboard 1138 and a pointing device such as a mouse 1140. Other input devices (not shown) may include a microphone, IR remote control, joystick, game pad, stylus pen, touch screen, and the like. Although these and other input devices are often connected to the processing unit 1104 through an input device interface 1142 that is connected to the system bus 1108, a parallel port, IEEE 1394 serial port, game port, USB port, IR interface, may be connected by other interfaces such as the like.

A monitor 1144 or other type of display device is also connected to the system bus 1108 through an interface such as a video adapter 1146. In addition to the monitor 1144, computers typically include other peripheral output devices (not shown) such as speakers, printers, and the like.

Computer 1102 may operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s) 1148 via wired and/or wireless communications. Remote computer(s) 1148 may be a workstation, computing device computer, router, personal computer, handheld computer, microprocessor-based entertainment device, peer device, or other common network node, and generally includes It includes many or all of the components described for, but for simplicity, only memory storage device 1150 is shown. The logical connections shown include wired/wireless connections to a local area network (LAN) 1152 and/or a larger network, such as a wide area network (WAN) 1154 . Such LAN and WAN networking environments are common in offices and corporations and facilitate enterprise-wide computer networks, such as intranets, all of which can be connected to worldwide computer networks, such as the Internet.

When used in a LAN networking environment, computer 1102 connects to local network 1152 through wired and/or wireless communication network interfaces or adapters 1156. Adapter 1156 may facilitate wired or wireless communications to LAN 1152, which also includes a wireless access point installed therein to communicate with wireless adapter 1156. When used in a WAN networking environment, computer 1102 may include a modem 1158, be connected to a communicating computing device on WAN 1154, or establish communications over WAN 1154, such as over the Internet. have other means. A modem 1158, which may be internal or external and a wired or wireless device, is connected to the system bus 1108 through a serial port interface 1142. In a networked environment, program modules described for computer 1102, or portions thereof, may be stored on remote memory/storage device 1150. It will be appreciated that the network connections shown are exemplary and other means of establishing a communication link between computers may be used.

Computer 1102 is any wireless device or entity that is deployed and operating in wireless communication, eg, printers, scanners, desktop and/or portable computers, portable data assistants (PDAs), communication satellites, wireless detectable tags associated with It operates to communicate with arbitrary equipment or places and telephones. This includes at least Wi-Fi and Bluetooth wireless technologies. Thus, the communication may be a predefined structure as in conventional networks or simply an ad hoc communication between at least two devices.

Wi-Fi (Wireless Fidelity) makes it possible to connect to the Internet without wires. Wi-Fi is a wireless technology, such as a cell phone, that allows such devices, eg, computers, to transmit and receive data both indoors and outdoors, i.e. anywhere within coverage of a base station. Wi-Fi networks use a radio technology called IEEE 802.11 (a, b, g, etc.) to provide secure, reliable, and high-speed wireless connections. Wi-Fi can be used to connect computers to each other, to the Internet, and to wired networks (using IEEE 802.3 or Ethernet). Wi-Fi networks can operate in the unlicensed 2.4 and 5 GHz radio bands, for example, at 11 Mbps (802.11a) or 54 Mbps (802.11b) data rates, or in products that include both bands (dual band) .

Those skilled in the art will understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, instructions, information, signals, bits, symbols and chips that may be referenced in the above description are voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields s or particles, or any combination thereof.

Those skilled in the art will understand that the various illustrative logical blocks, modules, processors, means, circuits, and algorithm steps described in connection with the embodiments disclosed herein are electronic hardware, (for convenience) , may be implemented by various forms of program or design code (referred to herein as software) or a combination of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the particular application and the design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

Various embodiments presented herein may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques. The term article of manufacture includes a computer program, carrier, or media accessible from any computer-readable storage device. For example, computer-readable storage media include magnetic storage devices (eg, hard disks, floppy disks, magnetic strips, etc.), optical disks (eg, CDs, DVDs, etc.), smart cards, and flash memory devices (eg, EEPROM, cards, sticks, key drives, etc.), but are not limited thereto. Additionally, various storage media presented herein include one or more devices and/or other machine-readable media for storing information.

It is to be understood that the specific order or hierarchy of steps in the processes presented is an example of example approaches. Based upon design priorities, it is to be understood that the specific order or hierarchy of steps in the processes may be rearranged within the scope of this disclosure. The accompanying method claims present elements of the various steps in a sample order, but are not meant to be limited to the specific order or hierarchy presented.

The scope of rights to a method in the claims of the present disclosure is caused by the functions and features described in each step, and unless the order of precedence is specified in each step constituting the method, the claims The order in which the steps in the scope are listed is not affected. For example, in a claim described in a method including steps A and B, even if step A is described before step B, the scope of rights is not limited to the fact that step A must precede step B.

The description of the presented embodiments is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to these embodiments will be apparent to those skilled in the art of this disclosure, and the general principles defined herein may be applied to other embodiments without departing from the scope of this disclosure. Thus, the present disclosure is not to be limited to the embodiments presented herein, but is to be interpreted in the widest scope consistent with the principles and novel features presented herein.

Claims (8)

In the method of deriving and designing system requirements using a processor of a computing device,
Deriving requirements for safety and security of the design target system;
Based on the requirements, designing the design target system; and
determining whether the design target system satisfies the requirements;
including,
The above requirements are
Identifying components of the design target system, and a data flow diagram generated based on the components;
a library of problems related to vulnerabilities of the system to be designed based on a plurality of data and methods of attacking the system to be designed;
Anticipated problems that may occur in the design target system recognized based on preset safety and security attributes;
a problem tree generated based on an identification problem generated by applying the expected problem to the data flow chart and the problem library; and
a degree of risk for the identification problem generated based on the problem tree;
derived based on,
How to derive and design system requirements.
delete According to claim 1,
Based on the requirements, the step of designing the design target system,
A subsystem of the system to be designed is identified based on a preset standard identification method, a unit of each of the plurality of modules is identified based on the subsystem, and used in each of the plurality of modules based on the plurality of modules. identifying the parameters to be;
setting a safety range of each of the subsystem, the plurality of modules, and the parameter based on preset safety information;
identifying a correlation between the plurality of modules based on a call graph representing a call relationship between the plurality of modules;
verifying the safety range based on preset safety information, determining a complexity of each of the plurality of modules based on a correlation between the plurality of modules, and simplifying each of the plurality of modules;
verifying the problem library based on the plurality of materials, and deriving a probability value of the identification problem according to a preset standard;
verifying the data flow chart based on a preset creation criterion; and
determining whether minimum complexity of each of the plurality of modules is satisfied by using a program design language;
including,
How to derive and design system requirements.
According to claim 1,
Based on the risk, the step of deriving the requirements,
based on the degree of risk, determining a degree of importance for the identification problem;
determining, based on the degree of importance, whether the requirement for solving the identification problem is implemented; and
deriving the requirements if the requirements are implemented;
including,
How to derive and design system requirements.
According to claim 1,
Deriving a risk for the identification problem based on the problem tree,
Damage possibility information, which is the degree of damage when the identification problem occurs, reproducibility information, which is difficulty for reproducing the identification problem, abuse possibility information, which is the need for knowledge to generate the identification problem, and influence when the identification problem occurs setting a score and deriving the degree of risk based on user information, which is the number of users receiving the problem, and discoverability information, which is difficulty for discovering the identification problem;
including,
How to derive and design system requirements.
According to claim 3,
The step of determining whether the minimum complexity of each of the plurality of modules is satisfied using the program design language,
checking whether the minimum complexity is satisfied by using a pseudo code or source code for a predetermined complexity measurement algorithm;
including,
How to derive and design system requirements.
According to claim 1,
The data flow diagram is
Including information on each of the plurality of functions provided by the design target system and information on data transmitted and received between the plurality of functions,
How to derive and design system requirements.
According to claim 1,
The problem tree is
contain information about the ultimate attack target;
The final attack target is placed at the top node of the problem tree,
At least one problem related to the final attack target is placed in at least one lower node associated with the top node,
How to derive and design system requirements.

Images