WO2023096152A1 - 단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법, 이를 수행하기 위한 기록 매체 및 장치 - Google Patents

단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법, 이를 수행하기 위한 기록 매체 및 장치 Download PDF

Info

Publication number
WO2023096152A1
WO2023096152A1 PCT/KR2022/015342 KR2022015342W WO2023096152A1 WO 2023096152 A1 WO2023096152 A1 WO 2023096152A1 KR 2022015342 W KR2022015342 W KR 2022015342W WO 2023096152 A1 WO2023096152 A1 WO 2023096152A1
Authority
WO
WIPO (PCT)
Prior art keywords
test
unit
test case
security
unit test
Prior art date
Application number
PCT/KR2022/015342
Other languages
English (en)
French (fr)
Inventor
이정현
조해현
심경민
이선준
전거창
Original Assignee
숭실대학교 산학협력단
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
Application filed by 숭실대학교 산학협력단 filed Critical 숭실대학교 산학협력단
Publication of WO2023096152A1 publication Critical patent/WO2023096152A1/ko

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Definitions

  • the present invention relates to a method for detecting security design flaws based on unit test cases, a recording medium and an apparatus for performing the same, and more particularly, helps to evaluate security vulnerabilities that may occur due to unrestricted and incorrectly implemented operations of software systems. It relates to a method for detecting security design flaws based on unit test cases that can give
  • these security vulnerabilities can be mainly caused by memory corruption errors such as out-of-bounds memory access or use of uninitialized memory, and security design flaws.
  • memory corruption errors such as buffer overflow, out-of-bound access, use-after-free, and double-free are significant security issues affecting programs developed in unsafe languages (such as C and C++). am.
  • the majority of memory corruption errors are caused by programming errors, and these errors occur frequently due to the size and complexity of actual software.
  • a hacker attacker
  • These memory corruption errors have remained at the top of dangerous software vulnerabilities for the past 27 years and rank fifth in the Top 25 Most Dangerous Software Vulnerabilities of 2020.
  • the Apache Struts framework which is used for Java web application development based on the MVC framework, has serious vulnerabilities because it cannot control unlimited operations in this framework.
  • the Apache Struts framework supports Object-Graph Navigation Language (OGNL) expressions used to get or set the property values of Java objects, and can execute OGNL expressions received in HTTP requests. Therefore, because OGNL expressions can access internal objects containing sensitive data in the system, their execution had to be carefully controlled.
  • OGNL Object-Graph Navigation Language
  • the Apache Struts framework lacks such a control mechanism, which leads to many serious vulnerabilities that allow arbitrary code execution. I had no choice but to Hackers exploited these vulnerabilities by leaking credential files using OGNL expressions or inserting exploit code into HTTP request tags by opening backdoors.
  • Figure 1 shows a partial list of vulnerabilities that can be exploited to execute arbitrary code in Apache Struts. As can be seen from the average CVSS score (8.3), the severity is very high, and 23 of them allow hackers to code remotely. was able to run These vulnerabilities found in Apache Struts clearly show that unrestricted operation of software due to design flaws can lead to serious security vulnerabilities.
  • Shellshock is a vulnerability found in the Unix Bash shell that allows hackers to gain unauthorized access and execute arbitrary code through a vulnerability that allows execution of arbitrary commands in environment variables that should not be used. could get Hackers started exploiting the Shellshock vulnerability hours after the initial disclosure, and millions of actual hacks involving the vulnerability were recorded in just a few days.
  • Table 2 is a list of vulnerabilities related to Shellshock and their severity.
  • This second example demonstrates that a design flaw can be a significant cybersecurity threat affecting millions of users. In particular, the fact that it took 22 years from the first release of the version of Bash affected by these vulnerabilities to the discovery of the vulnerabilities makes it very important to evaluate design flaws from a security perspective and represent a potential cybersecurity threat. This is an example showing that it is an essential task to remove .
  • Heartbleed is a serious security vulnerability in the OpenSSL cryptographic software library, which provides Secure Sockets Layer/ Transport Layer Security (SSL/TLS) encryption used for Internet security. Exploitation of this vulnerability could read 64 KB of memory because it does not check that the length of the payload matches the payload contained in the Heartbeat request message.
  • Heartbeat allows TLS and Datagram Transport Layer Security (DTLS) protocols to maintain communication connections without having to renegotiate the connection each time. And when the server responds to the heartbeat, it returns the length of the payload received as requested in memory. Sensitive information such as private keys stored in system memory can therefore be leaked, and this security design flaw has left many websites vulnerable.
  • SSL/TLS Secure Sockets Layer/ Transport Layer Security
  • automated vulnerability detection methods include fuzzing, symbolic execution, and taint analysis.
  • fuzzing symbolic execution
  • taint analysis a process for detecting vulnerabilities due to security design flaws.
  • Patent Document 1 Korea Patent Publication No. 1
  • the present invention has been made to solve the above problems, and an object of the present invention is a unit test case capable of detecting security vulnerabilities due to security design flaws that may occur due to unrestricted and incorrectly implemented operations of a software system. based security design flaw detection method, and to provide a recording medium and device for performing the same.
  • a method for detecting security design flaws based on unit test cases performed in a security design flaw detection apparatus for detecting security design flaws in a software system includes the software from an external device. Collecting unit test cases for the system and pre-processing the unit test cases; generating a first test case by testing whether the software system violates a security policy using preprocessed unit test cases; generating a second test case that is a data set for testing functions of the software system based on the first test case; and detecting vulnerabilities of the software system by executing the second test case.
  • code fragments included in the unit test cases may be classified, and the unit test cases may be combined or changed based on the classified code fragments for preprocessing.
  • the generating of the first test case may include performing a first security policy test to check whether permission is granted through an access control check on the preprocessed unit test case; performing a second security policy test to check whether or not unauthorized data has been changed or tampered with through an integrity check on the preprocessed unit test case; and performing a third security policy test to check whether data is encrypted through a confidentiality check on the preprocessed unit test case.
  • the performing of the first security policy test, the second security policy test, and the third security policy test may be performed according to a preset order.
  • the second test case is generated by manipulating the first test case with randomly generated data types and values, or the unit test case that has not been preprocessed is used as the first test case.
  • the second test case may be generated by combining with a case.
  • a computer program for performing the unit test case based security design defect detection method is recorded in a computer readable storage medium according to an embodiment of the present invention for achieving the above object.
  • an apparatus for detecting security design flaws based on unit test cases for detecting security design flaws in a software system collects unit test cases for the software system from an external device. and a pre-processing unit for pre-processing the unit test cases; a security policy test unit generating a first test case by testing whether the software system violates the security policy using preprocessed unit test cases; a test case generating unit generating a second test case, which is a data set for testing functions of the software system, based on the first test case; and a vulnerability detection unit configured to detect vulnerabilities of the software system by executing the second test case.
  • the preprocessing unit may classify code fragments included in the unit test cases, and perform preprocessing by combining or changing the unit test cases based on the classified code fragments.
  • the security policy test unit may include an access control checker performing a first security policy test to check whether permission is granted through an access control check on the preprocessed unit test case; a data integrity verifier performing a second security policy test to check whether data has been altered or tampered with without permission through an integrity check on the preprocessed unit test case; and a data confidentiality maintainer performing a third security policy test to check whether data is encrypted through a confidentiality check on the preprocessed unit test case.
  • the first security policy test, the second security policy test, and the third security policy test may be performed according to a preset order.
  • the test case generating unit includes: a random generator generating the second test case by manipulating the first test case with randomly generated data types and values; and a combination generator generating the second test case by combining the unpreprocessed unit test case with the first test case.
  • 1 and 2 are diagrams for explaining security vulnerabilities due to design flaws
  • FIG. 3 is a diagram for explaining the configuration of a security design flaw detection device 100 according to an embodiment of the present invention
  • FIG. 4 is a diagram for explaining the detailed configuration of a security design flaw detection device 100 according to an embodiment of the present invention.
  • 5 and 6 are diagrams for explaining test cases generated by the device 100 for detecting security design flaws according to the present embodiment
  • FIG. 7 and 8 are diagrams for explaining a process of detecting a vulnerability in the security design flaw detection device 100 according to this embodiment
  • FIG. 9 is a diagram for explaining the types of vulnerabilities detected by the device 100 for detecting security design flaws according to this embodiment.
  • FIG. 10 is a flowchart illustrating a security design defect detection method according to an embodiment of the present invention.
  • the components according to the present invention are components defined not by physical division but by functional division, and may be defined by the functions that each performs.
  • Each of the components may be implemented as hardware or program codes and processing units that perform respective functions, and the functions of two or more components may be implemented by being included in one component. Therefore, the names given to the components in the following embodiments are not to physically distinguish each component, but to imply the representative function performed by each component, and the names of the components indicate the present invention. It should be noted that the technical idea of is not limited.
  • Figure 3 is a diagram for explaining the configuration of a security design flaw detection device 100 according to an embodiment of the present invention
  • Figure 4 is a detailed configuration of the security design flaw detection device 100 according to an embodiment of the present invention
  • 5 and 6 are drawings for explaining test cases generated by the device 100 for detecting security design flaws according to this embodiment
  • FIGS. 7 and 8 are drawings for security design flaw detection according to this embodiment.
  • FIG. 9 is a diagram for explaining types of vulnerabilities detected by the device 100 for detecting security design flaws according to the present embodiment.
  • unauthorized operations can be performed due to security vulnerabilities in software.
  • the most common security vulnerabilities are caused by memory corruption bugs, and these bugs can be caused by programmer mistakes and source code errors. there is.
  • the device 100 for detecting security design flaws may be provided to detect security vulnerabilities based on an unrestricted and incorrectly implemented operation of a system.
  • the device 100 for detecting security design flaws according to this embodiment may evaluate vulnerabilities through security policies using test cases of target programs.
  • the device 100 for detecting security design flaws defines two abnormal behaviors of the software system that can be caused by design flaws.
  • One is an unrestricted behavior, which is an unrestricted behavior, and the other is an incorrectly implemented behavior. (Misimplemented behavior).
  • unrestricted operation that is, unrestricted operation
  • SQL injection can lead to serious data breaches by maliciously injecting and executing arbitrary SQL queries to manipulate databases into behaving abnormally, which is caused by not properly checking allowed input types and values. It's a vulnerability.
  • an erroneously implemented operation may be a result of an incorrect or improperly implemented function from a security point of view.
  • the focus is on detecting an erroneously implemented operation due to improper implementation. This could be the case, for example, when a program encrypts bad data (other than the data it needs to encrypt) when it performs cryptographic operations with poorly implemented behavior.
  • the security design defect detection device 100 of the present invention which detects security vulnerabilities based on such unrestricted operations and incorrectly implemented operations, automatically detects complex and ambiguous test cases based on unit test cases of a system implemented by a developer.
  • unit test cases can contain code that should work correctly as expected, rather than code that creates errors.
  • the security design defect detection apparatus 100 for detecting vulnerabilities in the software system of the present invention can detect undefined and incorrectly implemented operations in the target software system through automatically generated test cases.
  • software (application) for performing a security design flaw detection method may be installed and executed, and the pre-processing unit 110, the security policy test unit 130, and the test case It may be provided by including a generating unit 150 and a vulnerability detection unit 170 .
  • the pre-processing unit 110 may collect unit test cases, which are codes previously implemented by a developer for a software system stored in an external device, from an external device and pre-process the collected unit test cases.
  • the preprocessing may be preprocessing the unit test cases by classifying code fragments included in the collected unit test cases and combining or changing the classified code fragments.
  • the pre-processing unit 110 may include a crawler 111, a classifier 113, and a parser 115.
  • Collector 111 can collect unit test cases for target software systems from external devices such as official repositories including web pages and the like over the network, and in general, most software systems have basic codes for testing each function. It contains unit test cases which are snippets.
  • the collector 111 since the collector 111 needs to use the corresponding information after collecting the unit test cases, it can also collect the degree of the source of the code, such as the URL where the unit test case is located and the path stored inside the source repository. For example, assuming you got the code template via "https://github.com/ros/ros_tutorials/tree/noetic-devel/rospy_tutorials/001_talker_listener/talker.py", in this case the code template is the noetic version of ROS. , and you can see from the URL that this is a unit test to test the functionality between the talker and the listener from the talker's point of view.
  • the classifier 113 may classify the code pieces collected by the collector 111 into classes, functions, annotations, and variables. Then, the classified code snippet may be delivered to the analyzer 115 .
  • the analyzer 115 may combine or change code pieces, that is, unit test cases, which are data classified by the classifier 113, to generate test cases for discovering unrestricted and incorrectly implemented operations of the target software system.
  • the analyzer 115 modifies and preprocesses the intuitively recognizable function of each unit test case, rather than analyzing the logical flow or meaning of each unit test case, so that the operation of the target software system can be identified. For example, if a function is called using a specific variable in a unit test case, the analyzer 115 may randomly modify the value of the variable by generating a test case that calls the corresponding function. Comments for each unit test case can also be provided to the user to indicate the intended function of the target software system. Based on this information, users can find the intended function of the target software system without manually analyzing the target software system or unit test cases.
  • the analyzer 115 cannot provide enough information to the user in poorly developed unit test cases that do not have adequate descriptions to describe the function under test. Only information such as cases may be provided to the user.
  • the preprocessed unit test cases which are data obtained by combining or changing unit test cases in the analyzer 115 , may be transmitted to the security policy test unit 130 .
  • the security policy test unit 130 may generate a first test case TC1 by testing whether the target software system violates the security policy using the unit test case preprocessed by the preprocessor 110 .
  • any security policy is tightly coupled to system functionality, and functional testing involves the execution of many security mechanisms.
  • the security policy can provide sufficient confidence in the security mechanism.
  • the security required for the corresponding software system is performed through the security policy test performed by the security policy test unit 130 of the present invention. You get proof that the implementation of the security policy for the policy is correct.
  • the security policy test unit 130 can show the security policy that can occur from the security point of view of the target software system by using the preprocessed unit test cases, and the user can properly perform the target software system through the security policy. You will be able to understand and verify that it has been implemented.
  • security design flaw detection device 100 There are a wide variety of categories to which security policies are applied in the target software system.
  • security design flaw detection device 100 among the characteristics of the system, data transmission security is focused, and unrestricted and misimplemented operations may occur. Security problems can be prevented in advance.
  • the data security policy determines the types of operations permitted to users with access rights and to each user of the entity. And it may be provided, including a data confidentiality keeper (135).
  • the access control checker 131 may perform a first security policy test to check whether authorization is granted through access control checks on preprocessed unit test cases.
  • the access control checker 131 may identify detailed security or authorization functions such as role-based access to functions of the target software system, user access rights, and function partitioning. Accordingly, the access control checker 131 may perform a first security policy test to determine whether functions such as administrator privileges and privilege elevation operating in the target software system are granted through control.
  • the data integrity verifier 133 may perform a second security policy test to check whether data has been altered or tampered with without permission through an integrity check on preprocessed unit test cases. Data must be protected from unauthorized alteration or tampering, and data integrity can protect against the security risk of tampering with unauthorized information interception and alteration. In addition to protecting the data stored within the network, this data integrity requires an additional security element to ensure data integrity when untrusted data is transmitted to the system. When data entering the system is received on a public network, it should be protected from sniffing and interpretation, usually by encryption, and it should be ensured that the data has not been tampered with. To this end, the data integrity verifier 133 may perform a second security policy test to check whether data has been changed or falsified.
  • the data confidentiality maintainer 135 may perform a third security policy test to check whether data is encrypted through a confidentiality check on preprocessed unit test cases.
  • Data confidentiality means that information is disclosed only to authorized users, and the contents of transmitted data are completely protected to prevent unauthorized users, that is, unauthorized persons from accessing the actual contents of the information. Confidentiality, which is guaranteed to be confidential and can prevent the disclosure of unwanted information, can mainly protect data from acts related to data hijacking, and can confirm whether or not encryption is used, which is the most popular method of use. .
  • the data confidentiality keeper 135 may perform a third security policy test to check whether such data is encrypted.
  • the security design defect detection device 100 performs a first security policy test performed by the access control checker 131, a second security policy test performed by the data integrity verifier 133, and a data confidentiality maintainer 135.
  • the third security policy test may be performed according to a preset order. This predetermined order may be an order set by a system developer using the security design defect detection device 100, and the security policy testing unit 130 may sequentially perform the first to third security policies according to the set order.
  • the third security policy test performed by the data confidentiality 135 is shown to be performed last, but this is merely an example for convenience of explanation, and is not limited thereto.
  • the first test case TC1 which is a preprocessing unit test case in which all security policy tests are completed, may be transferred to the test case generation unit 150 together with the result of the security policy test.
  • the result of the security policy test may also be included in the first test case TC1.
  • test case generating unit 150 generates a second test case TC2, which is a data set for testing the function of the target software system, based on the first test case TC1 transmitted from the security policy testing unit 130. can create
  • the security policy that may be violated in the target software system is applied to the first test case TC1 to generate the second test case.
  • test case generation unit 150 is not limited and in order to maximize the possibility of discovering an incorrectly implemented operation, rather than generating a second test case TC2 capable of testing specific functions of the target software system, various It may be desirable to generate a second test case (TC2) capable of testing functions as shown in FIGS. 5 and 6, and for this, the test case generator 150 includes a random generator 151 and a combination generator 153) may be included.
  • a random generator (R.A.G) 151 may generate the second test case by manipulating the first test case with randomly generated data types and values. Specifically, the random generator 151 changes the code snippets included in the first test case TC1 into randomly generated data types and values to manipulate the values (data) inside the unit test case, so that the second test case TC2 ) can be created as a single unit test case.
  • the combination generator 153 may generate the second test case TC2 by combining the unpreprocessed unit test case with the first test case TC1.
  • the combination generator 153 combines the unit test cases collected by the collector 111, that is, a plurality of unit test cases that have not been preprocessed through the analyzer 115, into the first test case TC1, and the second unit test case TC1 is combined.
  • a test case (TC2) can be created.
  • the number of unpreprocessed unit test cases coupled to the first test case TC1 may be arbitrarily determined or determined according to a preset number.
  • the combination generator 153 may allow the user to specify a unit test case to be combined with the first test case TC1.
  • the vulnerability detection unit 170 may detect system vulnerabilities by executing the second test case TC2 generated through the random generator 151 or the combined generator 153 .
  • the device 100 for detecting security design flaws includes a communication unit or an input unit for collecting or receiving various necessary information including unit test cases, as well as the collected unit test cases. It may include a storage unit that stores various information necessary for preprocessing and analysis to generate a test case, and an output unit that can output the result.
  • ROS is an open-source meta operating system (a collection of software frameworks) for robotics, and currently ROS is used in many academic projects and commercial products.
  • ROS can implement hardware abstraction, low-level device control, frequently used functions provided by general operating systems, and provide inter-process message passing and package management functions. It also provides tools and libraries to work with multiple systems, and has a significant level of complexity, including distributed computation, multi-threading, event-driven programming, and other system core concepts.
  • ROS proceeds through message communication between nodes, and nodes must register information with the master when starting. And the master has the information of each node and plays an important role in managing the nodes.
  • masters can also fail, and unrestricted or poorly implemented behavior in a master can negatively affect the entire system.
  • Remote mode execution vulnerabilities including CVE-2016-10681, were also found in ROS, a representative meta OS for robots, and many MiR robots were exposed to vulnerabilities due to design flaws in the calculation graph package provided by ROS.
  • ROS has several unit test cases designed to verify interactions between basic functions, services, and nodes, and it is possible to discover unrestricted or incorrectly implemented behaviors in these ROS using the security design flaw detection device 100 of the present invention. Created test cases for
  • fuzzy test cases are generated as test cases using the security design flaw detection device 100 according to the present embodiment and executed in ROS. was monitored.
  • FIGS. 5 and 6 are diagrams showing code fragments of test cases generated by the device 100 for detecting security design flaws. As shown in each drawing, the device 100 for detecting security design flaws may provide a user with a brief description of modules evaluated in each test case.
  • the device 100 for detecting security design flaws of the present invention detected vulnerabilities by identifying unrestricted operations and incorrectly implemented operations in the XMLRPC module and TCPROS module of ROS in numerous generated test codes. In addition, it was confirmed that the detected vulnerabilities can be exploited from the first released ROS version to the latest version.
  • FIG. 7 is a diagram showing the process of registering new information of a node in the master as described above, and an unlimited operation was detected by executing a test case registering a listener of the same name.
  • the Talker node and the Listener node must be registered in the master node to communicate with each other.
  • Figure 5 a node named "listener” is initially registered with the master, and another node named “listener” sends a registration request to the master. The previously registered "listener" node is unregistered through a test case. found that there is
  • the master node After manually analyzing the root cause of the vulnerability, we found a problem in the XMLRPC communication module used by the master node to initiate connections between nodes (e.g. talker and listener).
  • nodes e.g. talker and listener.
  • the master node received a request from a talker and a node that wants to become a talker, the master did not perform authentication procedures to register the node as a listener or talker.
  • FIG. 7 shows a code snippet for registering a new node in the XMLRPC module.
  • a registration request is received from a node, only the API value corresponding to the node address is checked. If the previous API value and the requested API value are different, the XMLRPC module requests without additional confirmation. Set the bumped API as bumped_api. Therefore, if a new node with the same name as the previously registered node requests a listener, the existing service is canceled and a new connection is started. As a result, the malicious node in ROS becomes a listener and intercepts the data traffic between the two nodes. show that you can
  • FIG. 8 is a diagram for checking md5sum and string message type codes used in ROS.
  • the test case shown in FIG. 6 that is, the second test case generated by the device 100 for detecting security design flaws is a test case in which randomly generated arguments are sent to the talker node.
  • the hash function for message integrity check was not used properly.
  • FIG. 8 shows a function using the md5sum hash in the TCPROS module.
  • the function instead of hashing the message body containing the actual data of the message, only the message type is hashed to generate the md5sum. Therefore, even if the message is different, the md5sum value of the message is the same, and as a result, ROS has a vulnerability where it is possible to forge each message without going through the verification process.
  • the types of vulnerabilities that can be detected by the device 100 for detecting security design flaws according to the present invention are as shown in FIG. 9 .
  • a check mark (v) in the drawing indicates a detectable vulnerability type.
  • Code Injection Vulnerability is a malicious code that can be inserted into a system to create a payload and be executed. This vulnerability occurs when a program does not properly restrict or check input values exist. Accordingly, the device 100 for detecting security design flaws may generate test cases using predefined values or symbols used to cause such vulnerabilities.
  • Data Validation Vulnerability occurs when data type verification is incorrectly implemented, and the device 100 for detecting security design flaws according to the present embodiment is used as a second test case to intentionally target software systems. You can create test cases that cause improper use of data types for your data types, and you can create test cases that execute several arbitrary functions in arbitrary order. These test cases can be used to uncover types of data validation vulnerabilities because they can use or manipulate data structures that have arbitrary functionality not implemented for data structures.
  • the apparatus 100 for detecting security design flaws may generate and provide a test case using various data and a second test case capable of testing interactions between various functions of the system. This second test case may trigger an exception in the system, which may help detect vulnerabilities related to exception handling.
  • FIG. 9 shows that the security design defect detection device 100 according to the present embodiment can detect code injection, data verification, and exception handling vulnerabilities. Therefore, it can be seen that, unlike conventional vulnerability detection devices that stop at finding memory vulnerabilities, the security design defect detection device 100 of the present invention is effective in detecting vulnerabilities due to security design defects.
  • FIG. 10 is a flowchart for explaining a security design flaw detection method according to an embodiment of the present invention.
  • the security design flaw detection method according to an embodiment of the present invention is a software system shown in FIGS. 3 and 4 Since it is carried out on substantially the same configuration as the security design flaw detection device 100 for detecting security design flaws, the same reference numerals are given to the same components as the security design flaw detection device 100 of FIGS. 3 and 4. and repeated descriptions will be omitted.
  • the apparatus 100 for detecting security design flaws may collect unit test cases for the software system from an external device and pre-process the unit test cases (S110).
  • code pieces included in unit test cases may be classified, and unit test cases may be preprocessed by combining or changing unit test cases based on the classified code pieces.
  • a step of generating a first test case by testing whether the software system violates the security policy using the preprocessed unit test case may be performed (S130).
  • the step of generating the first test case is the step of performing a first security policy test (not shown) to check whether permission is granted through an access control check on the preprocessed unit test case (not shown), the preprocessed unit test case Performing a second security policy test (not shown) to check whether the data has been altered or tampered with through integrity check, and to check whether the data is encrypted through a confidentiality check on the preprocessed unit test case.
  • a step of performing a third security policy test may be included.
  • the steps of performing the first security policy test (not shown), the step of performing the second security policy test (not shown), and the step of performing the third security policy test (not shown) are performed according to a preset order. can be performed
  • a step of generating a second test case which is a data set for testing the function of the software system, based on the first test case may be performed (S150).
  • the second test case is generated by manipulating the first test case with randomly generated data types and values, or the unpreprocessed unit test case is combined with the first test case. to generate a second test case.
  • a step of detecting vulnerabilities of the software system by executing a second test case may be performed (S170).
  • the security design flaw detection method of the present invention may be implemented in the form of program instructions that can be executed through various computer components and recorded in a computer readable recording medium.
  • the computer readable recording medium may include program instructions, data files, data structures, etc. alone or in combination.
  • Program instructions recorded on the computer-readable recording medium may be those specially designed and configured for the present invention, or those known and usable to those skilled in the art of computer software.
  • Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks and magnetic tapes, optical recording media such as CD-ROMs and DVDs, and magneto-optical media such as floptical disks. media), and hardware devices specially configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like.
  • Examples of program instructions include high-level language codes that can be executed by a computer using an interpreter or the like as well as machine language codes such as those produced by a compiler.
  • the hardware device may be configured to act as one or more software modules to perform processing according to the present invention and vice versa.
  • access control checker 133 data integrity verifier

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Storage Device Security (AREA)
  • Computing Systems (AREA)

Abstract

본 발명은 소프트웨어 시스템에 대한 보안 설계 결함을 탐지하기 위한 보안 설계 결함 탐지 장치에서 수행되는 단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법에 관한 것으로, 단위 테스트 케이스를 전처리하는 단계; 전처리된 단위 테스트 케이스를 이용해 상기 소프트웨어 시스템이 보안 정책에 위배되는지 테스트하여 제1 테스트 케이스를 생성하는 단계; 상기 제1 테스트 케이스에 기초하여 상기 소프트웨어 시스템의 기능을 테스트하기 위한 데이터 집합인 제2 테스트 케이스를 생성하는 단계; 및 상기 제2 테스트 케이스를 실행하여 상기 소프트웨어 시스템의 취약점을 탐지하는 단계를 포함한다. 이를 통해 소프트웨어 시스템의 제한되지 않고 잘못 구현된 동작으로 인해 발생할 수 있는 보안 설계 결함에 의한 보안 취약점을 탐지할 수 있다.

Description

단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법, 이를 수행하기 위한 기록 매체 및 장치
본 발명은 단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법, 이를 수행하기 위한 기록 매체 및 장치에 관한 것으로 보다 상세하게는 소프트웨어 시스템의 제한되지 않고 잘못 구현된 동작으로 인해 발생할 수 있는 보안 취약성을 평가하는데 도움을 줄 수 있는 단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법, 이를 수행하기 위한 기록 매체 및 장치에 관한 것이다.
IoT 시장이 계속해서 성장하는 가운데, IoT 장치 들은 매년 증가하여 2021년까지 250억 개로 증가할 것으로 예상된다. 이러한 환경에서 모바일 기기의 중요성도 커지면서, 모바일 애플리케이션의 시장도 가파르게 성장하고 있다.
하지만 소프트웨어 시스템의 설계 결함으로 인한 보안 취약성이 실제 시스템에 지속해서 나타나고 있으며, 이러한 보안 설계 결함은 제한되지 않고 잘못된 시스템 동작을 유발할 수 있으며, 원격 코드 실행 또는 민감한 데이터 유출과 같은 치명적인 취약점으로 이어질 수 있다.
이러한 시스템의 제한되지 않고 잘못된 동작을 발견하는 것은 필수적인 작업이지만, 전체 코드를 자세히 분석하는 것은 시간이 오래 걸리고 오류가 발생하기 쉬우므로 보안 전문가가 이러한 취약점을 미리 발견하는 것은 어렵다는 한계가 존재한다.
그리고 일반적으로 이러한 보안 취약점은 범위를 벗어난 메모리 액세스 또는 초기화되지 않은 메모리 사용과 같은 메모리 손상 오류, 그리고 보안 설계 결함이 주요 원인일 수 있다.
구체적으로 buffer overflow, out-of-bound access, use-after-free 및 double-free와 같은 메모리 손상 오류는 안전하지 않은 언어(예를 들어 C 및 C++)로 개발된 프로그램에 영향을 미치는 중요한 보안 문제이다. 메모리 손상 오류의 대부분은 프로그래밍 오류로 인해 발생하는데, 이러한 오류는 실제 소프트웨어의 크기와 복잡성으로 인해 자주 발생한다. 따라서 취약점을 악용하여 해커(공격자)는 주소를 변경하여 악성 코드 조각을 실행하거나 메모리의 민감한 데이터에 접근(액세스)할 수 있다. 이러한 메모리 손상 오류는 지난 27년동안 여전히 위험한 소프트웨어 취약점의 최상위 순위였으며 2020년 가장 위험한 소프트웨어 취약점 상위 25개에서 5위를 차지하였다.
한편 설계 결함은 수 많은 사용자에게 심각한 보안 위협이 될 수 있는데, 이러한 보안 위협이 된 실제 사례를 살펴보면 다음과 같다.
먼저 MVC 프레임워크를 기반으로 Java 웹 애플리케이션 개발에 사용되는 Apache Struts 프레임워크는 이 프레임워크에서 무제한 동작을 제어하지 못하기 때문에 심각한 취약점을 가지고 있었다. Apache Struts 프레임워크는 Java 개체의 속성 값을 가져오거나 설정하는데 사용되는 OGNL(Object-Graph Naviga-tion Language) 익스프레션(expressions)을 지원하고, HTTP요청에서 수신한 OGNL 익스프레션을 실행할 수 있다. 따라서 OGNL 익스프레션은 시스템의 민감한 데이터가 포함된 내부 개체에 접근할 수 있기 때문에 실행을 신중하게 제어해야 했지만, 불행히도 Apache Struts 프레임워크에는 이러한 제어 메커니즘이 없기 때문에 임의 코드 실행을 허용하는 심각한 취약점이 많이 발생할 수 밖에 없었다. 이에 해커는 OGNL 익스프레션을 사용하여 자격증명 파일을 유출하거나 백도어를 여는 방식으로 HTTP 요청 태그에 익스플로잇 코드(exploit code) 삽입하여 이러한 취약점을 악용하였다. 도 1은 Apache Struts에서 임의 코드 실행에 악용될 수 있는 취약점의 일부 목록을 보여주는 것으로, 평균 CVSS 점수(8.3)에서 알 수 있듯이 심각도가 매우 높은 것은 물론, 그 중 23개의 취약점으로 인해 해커가 원격 코드를 실행할 수 있었다. Apache Struts에서 발견된 이러한 취약점은 설계 결함으로 인한 소프트웨어의 무제한 동작이 심각한 보안 취약성을 초래할 수 있음을 분명하게 보여준다.
두번째로 Shellshock은 Unix Bash Shell에서 발견된 취약점으로, 임의의 명령을 실행할 수 있다는 취약점을 가지고 있어, 사용할 수 없어야 하는 환경 변수에서 임의의 명령을 실행하는 취약점을 통해 해커가 무단 액세스 및 임의 코드 실행을 얻을 수 있었다. 해커는 초기 공개 후 몇 시간 후에 Shellshock 취약점을 악용하기 시작했으며, 취약점과 관련된 수 백만 건의 실제 해킹이 단 며칠 만에 기록되었다. 표 2는 이러한 Shellshock과 관련된 취약점 목록과 심각도를 나타낸 리스트이다. 이러한 두번째 사례는 설계 결함이 수많은 사용자에게 영향을 미치는 중대한 사이버 보안 위협이 될 수 있음을 보여주는 것이다. 특히나 이러한 취약점의 영향을 받는 Bash 버전(version)의 첫 번째 출시(release) 이후 취약점이 발견될 때까지 22년이 걸렸다는 사실은 보안 측면에서 설계 결함을 평가하는 것이 매우 중요하며 잠재적인 사이버 보안 위협을 제거하는데 필수적인 작업임을 보여주는 사례이다.
마지막으로 Heartbleed는 인터넷 보안에 사용되는 SSL/TLS(Secure Sockets Layer/ Transport Layer Security) 암호화를 제공하는 OpenSSL 암호화 소프트웨어 라이브러리의 심각한 보안 취약점이다. 해당 취약점을 악용하면 Heartbeat 요청 메시지에 포함된 페이로드와 페이로드의 길이가 일치하는지 확인하지 않기 때문에 64KB 메모리를 읽을 수 있다. 이에 Heartbeat를 사용하면 TLS 및 DTLS(Datagram Transport Layer Security) 프로토콜에서 매번 연결을 재협상하지 않고도 통신 연결을 유지할 수 있다. 그리고 서버가 Heartbeat에 응답할 때 메모리에서 요청한 만큼 받은 페이로드의 길이만큼 반환하게 된다. 따라서 시스템 메모리에 저장된 개인 키와 같은 민감한 정보가 누출될 가능성이 있으며, 이러한 보안 설계 결함으로 인해 많은 웹 사이트가 취약해졌다.
이에 자동화된 취약점 탐지 방법으로 fuzzing, symbolic execution 및 Taint analysis 등이 있다. 하지만 대부분의 기존의 자동화된 취약점 탐지 접근 방식 및 방법은 프로그램에 존재하는 논리결함이나 메모리 손상을 유발하는 프로그램의 메모리 취약성을 발견하는 것에 그칠 뿐이므로, 보안 설계 결함으로 인한 취약점을 탐지하는 효과적인 방안이 필요하다.
[선행기술문헌]
[특허문헌]
(특허문헌 1) 한국공개특허공보 제 호
본 발명은 상기와 같은 문제를 해결하기 위해 안출된 것으로, 본 발명의 목적은 소프트웨어 시스템의 제한되지 않고 잘못 구현된 동작으로 인해 발생할 수 있는 보안 설계 결함에 의한 보안 취약점을 탐지할 수 있는 단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법, 이를 수행하기 위한 기록 매체 및 장치를 제공하는 것이다.
상기 목적을 달성하기 위한 본 발명의 일 실시예에 따른 소프트웨어 시스템에 대한 보안 설계 결함을 탐지하기 위한 보안 설계 결함 탐지 장치에서 수행되는 단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법은, 외부 장치로부터 상기 소프트웨어 시스템에 대한 단위 테스트 케이스를 수집하고, 상기 단위 테스트 케이스를 전처리하는 단계; 전처리된 단위 테스트 케이스를 이용해 상기 소프트웨어 시스템이 보안 정책에 위배되는지 테스트하여 제1 테스트 케이스를 생성하는 단계; 상기 제1 테스트 케이스에 기초하여 상기 소프트웨어 시스템의 기능을 테스트하기 위한 데이터 집합인 제2 테스트 케이스를 생성하는 단계; 및 상기 제2 테스트 케이스를 실행하여 상기 소프트웨어 시스템의 취약점을 탐지하는 단계를 포함한다.
그리고 상기 전처리하는 단계에서는, 상기 단위 테스트 케이스에 포함된 코드 조각을 분류하고, 분류된 코드 조각에 기초하여 상기 단위 테스트 케이스를 조합 또는 변경하여 전처리할 수 있다.
또한 상기 제1 테스트 케이스를 생성하는 단계는, 상기 전처리된 단위 테스트 케이스에 대한 접근 제어 검사를 통해 권한 부여 여부를 확인하는 제1 보안 정책 테스트를 수행하는 단계; 상기 전처리된 단위 테스트 케이스에 대한 무결성 검사를 통해 데이터의 무단 변경 또는 변조 여부를 확인하는 제2 보안 정책 테스트를 수행하는 단계; 및 상기 전처리된 단위 테스트 케이스에 대한 기밀유지 검사를 통해 데이터의 암호화여부를 확인하는 제3 보안 정책 테스트를 수행하는 단계를 포함할 수 있다.
여기서, 상기 제1 보안 정책 테스트를 수행하는 단계, 제2 보안 정책 테스트를 수행하는 단계 및 제3 보안 정책 테스트를 수행하는 단계는, 기설정된 순서에 따라 수행될 수 있다.
그리고 상기 제2 테스트 케이스를 생성하는 단계에서는, 상기 제1 테스트 케이스를 무작위로 생성된 데이터 유형 및 값으로 조작하여 상기 제2 테스트 케이스를 생성하거나, 전처리되지 않은 상기 단위 테스트 케이스를 상기 제1 테스트 케이스에 결합하여 상기 제2 테스트 케이스를 생성할 수 있다.
한편 상기 목적을 달성하기 위한 본 발명의 일 실시예에 따른 컴퓨터로 판독 가능한 저장 매체에는 상기 단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법을 수행하기 위한 컴퓨터 프로그램이 기록되어 있다.
상기 목적을 달성하기 위한 본 발명의 일 실시예에 따른 소프트웨어 시스템에 대한 보안 설계 결함을 탐지하기 위한 단위 테스트 케이스 기반의 보안 설계 결함 탐지 장치는, 외부 장치로부터 상기 소프트웨어 시스템에 대한 단위 테스트 케이스를 수집하고, 상기 단위 테스트 케이스를 전처리하는 전처리부; 전처리된 단위 테스트 케이스를 이용해 상기 소프트웨어 시스템이 보안 정책에 위배되는지 테스트하여 제1 테스트 케이스를 생성하는 보안 정책 테스트부; 상기 제1 테스트 케이스에 기초하여 상기 소프트웨어 시스템의 기능을 테스트하기 위한 데이터 집합인 제2 테스트 케이스를 생성하는 테스트 케이스 생성부; 및 상기 제2 테스트 케이스를 실행하여 상기 소프트웨어 시스템의 취약점을 탐지하는 취약점 탐지부를 포함한다.
그리고 상기 전처리부는, 상기 단위 테스트 케이스에 포함된 코드 조각을 분류하고, 분류된 코드 조각에 기초하여 상기 단위 테스트 케이스를 조합 또는 변경하여 전처리할 수 있다.
또한 상기 보안 정책 테스트부는, 상기 전처리된 단위 테스트 케이스에 대한 접근 제어 검사를 통해 권한 부여 여부를 확인하는 제1 보안 정책 테스트를 수행하는 액세스 제어 검사기; 상기 전처리된 단위 테스트 케이스에 대한 무결성 검사를 통해 데이터의 무단 변경 또는 변조 여부를 확인하는 제2 보안 정책 테스트를 수행하는 데이터 무결성 검증기; 및 상기 전처리된 단위 테스트 케이스에 대한 기밀유지 검사를 통해 데이터의 암호화여부를 확인하는 제3 보안 정책 테스트를 수행하는 데이터 기밀유지기를 포함할 수 있다.
여기서 상기 제1 보안 정책 테스트, 제2 보안 정책 테스트 및 제3 보안 정책 테스트는 기설정된 순서에 따라 수행될 수 있다.
그리고 테스트 케이스 생성부는, 상기 제1 테스트 케이스를 무작위로 생성된 데이터 유형 및 값으로 조작하여 상기 제2 테스트 케이스를 생성하는 무작위 생성기; 및 전처리되지 않은 상기 단위 테스트 케이스를 상기 제1 테스트 케이스에 결합하여 상기 제2 테스트 케이스를 생성하는 결합 생성기를 포함할 수 있다.
상술한 본 발명의 일측면에 따르면, 단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법, 이를 수행하기 위한 기록 매체 및 장치를 제공함으로써, 소프트웨어 시스템의 제한되지 않고 잘못 구현된 동작으로 인해 발생할 수 있는 보안 설계 결함에 의한 보안 취약점을 탐지할 수 있다.
도 1 및 도 2는 설계 결함으로 인한 보안 취약성을 설명하기 위한 도면,
도 3은 본 발명의 일 실시예에 따른 보안 설계 결함 탐지 장치(100)의 구성을 설명하기 위한 도면,
도 4는 본 발명의 일 실시예에 따른 보안 설계 결함 탐지 장치(100)의 세부구성을 설명하기 위한 도면,
도 5 및 도 6은 본 실시예에 따른 보안 설계 결함 탐지 장치(100)에서 생성되는 테스트 케이스를 설명하기 위한 도면,
도 7 및 도 8은 본 실시예에 따른 보안 설계 결함 탐지 장치(100)에서 취약점을 탐지하는 과정을 설명하기 위한 도면,
도 9는 본 실시예에 따른 보안 설계 결함 탐지 장치(100)에서 탐지된 취약점의 유형을 설명하기 위한 도면, 그리고,
도 10은 본 발명의 일 실시예에 따른 보안 설계 결함 탐지 방법을 설명하기 위한 흐름도이다.
후술하는 본 발명에 대한 상세한 설명은, 본 발명이 실시될 수 있는 특정 실시예를 예시로서 도시하는 첨부 도면을 참조한다. 이들 실시예는 당업자가 본 발명을 실시할 수 있기에 충분하도록 상세히 설명된다. 본 발명의 다양한 실시예는 서로 다르지만 상호 배타적일 필요는 없음이 이해되어야 한다. 예를 들어, 여기에 기재되어 있는 특정 형상, 구조 및 특성은 일 실시예와 관련하여 본 발명의 정신 및 범위를 벗어나지 않으면서 다른 실시예로 구현될 수 있다. 또한, 각각의 개시된 실시예 내의 개별 구성요소의 위치 또는 배치는 본 발명의 정신 및 범위를 벗어나지 않으면서 변경될 수 있음이 이해되어야 한다. 따라서, 후술하는 상세한 설명은 한정적인 의미로서 취하려는 것이 아니며, 본 발명의 범위는, 적절하게 설명된다면, 그 청구항들이 주장하는 것과 균등한 모든 범위와 더불어 첨부된 청구항에 의해서만 한정된다. 도면에서 유사한 참조부호는 여러 측면에 걸쳐서 동일하거나 유사한 기능을 지칭한다.
그리고 본 발명에 따른 구성요소들은 물리적인 구분이 아니라 기능적인 구분에 의해서 정의되는 구성요소들로서 각각이 수행하는 기능들에 의해서 정의될 수 있다. 각각의 구성요소들은 하드웨어 또는 각각의 기능을 수행하는 프로그램 코드 및 프로세싱 유닛으로 구현될 수 있을 것이며, 두 개 이상의 구성요소의 기능이 하나의 구성요소에 포함되어 구현될 수도 있을 것이다. 따라서 이하의 실시예에서 구성요소에 부여되는 명칭은 각각의 구성요소를 물리적으로 구분하기 위한 것이 아니라 각각의 구성요소가 수행되는 대표적인 기능을 암시하기 위해서 부여된 것이며, 구성요소의 명칭에 의해서 본 발명의 기술적 사상이 한정되지 않는 것임에 유의하여야 한다.
이하에서는 도면들을 참조하여 본 발명의 바람직한 실시예들을 보다 상세하게 설명하기로 한다.
도 3은 본 발명의 일 실시예에 따른 보안 설계 결함 탐지 장치(100)의 구성을 설명하기 위한 도면, 도 4는 본 발명의 일 실시예에 따른 보안 설계 결함 탐지 장치(100)의 세부구성을 설명하기 위한 도면, 도 5 및 도 6은 본 실시예에 따른 보안 설계 결함 탐지 장치(100)에서 생성되는 테스트 케이스를 설명하기 위한 도면, 도 7 및 도 8은 본 실시예에 따른 보안 설계 결함 탐지 장치(100)에서 취약점을 탐지하는 과정을 설명하기 위한 도면, 그리고 도 9는 본 실시예에 따른 보안 설계 결함 탐지 장치(100)에서 탐지된 취약점의 유형을 설명하기 위한 도면이다.
상술한 바와 같이 소프트웨어의 보안 취약점으로 인해 허용되지 않은 무단 작업이 수행될 수 있는데, 가장 일반적인 보안 취약점은 메모리 손상 버그로 인해 발생하는 것으로, 이러한 버그는 프로그래머의 실수와 소스코드의 오류로 인해 발생할 수 있다.
보안 취약점을 유발할 수 있는 이러한 버그는 프로그램을 중단시킬 수 있으므로 이상적으로는 소프트웨어 개발 및 테스트 중에 발견될 수 있고, 상술한 바와 같이 소프트웨어의 기능에는 영향을 미치지 않지만 올바르지 않거나 예기치 않거나 또는 의도하지 않은 동작을 유발할 수 있는 설계 결함은 원격 코드 실행과 같은 심각한 보안 취약성을 초래하여 수 많은 사용자를 위협할 수 있다. 특히 이러한 취약점은 자동화된 평가 도구의 부재에 의해 감지가 어렵고, 이에 따라 상술한 Shellshock 사례처럼 보안 결함이 매우 오랜시간동안 발견하지 못할 수 있다.
특히 개발자가 구현한 이러한 단위 테스트 케이스는 보안적인 측면을 고려하지 않고 구현된 경우가 많은데, 예를 들어 오류를 발생하는 코드가 포함되어 있지만 의도치 않게 제대로 작동하는 경우나, 제대로 작동을 해서 문제가 없는 것처럼 보이지만, 실제로는 오류를 발생시키는 경우가 발생하여 시스템의 취약점으로 이어질 수 있게 된다.
이에 본 발명의 일 실시예에 따른 보안 설계 결함 탐지 장치(100)는 시스템의 제한되지 않고 잘못 구현된 동작을 기반으로 보안 취약점을 탐지하기 위해 마련될 수 있다. 이러한 본 실시예의 보안 설계 결함 탐지 장치(100)는 대상 프로그램의 테스트 케이스를 가지고 보안 정책을 통해 취약점을 평가할 수 있다.
이 때 보안 설계 결함 탐지 장치(100)는 설계 결함이 가져올 수 있는 소프트웨어 시스템의 두 가지 비정상적인 동작을 정의하는데, 하나는 제한되지 않은 동작인 무제한 동작(unrestricted behavior)이고, 나머지 하나는 잘못 구현된 동작(Misimplemented behavior)일 수 있다.
여기서 무제한 동작, 즉 제한되지 않은 동작은 시스템이 자체적으로 또는 외부에서 요청한 작업을 적절하게 제한하거나 제한하지 않을 때 발생할 수 있다. 구체적으로 예를 들면 SQL 인젝션은 임의의 SQL 쿼리를 악의적으로 주입하고 실행하여 데이터베이스가 비정상적으로 작동하도록 조작하여 심각한 데이터 유출 사고로 이어질 수 있는데, 이는 허용되는 입력 유형 및 값을 제대로 검사하지 않아 발생하는 취약점이다.
한편 잘못 구현된 동작은 보안의 관점에서 기능이 잘못되었거나 부적절하게 구현된 결과일 수 있는데, 본 발명에서는 부적절한 구현으로 인해 잘못 구현된 동작을 감지하는 것에 중점을 두기로 한다. 예를 들어 프로그램이 잘못 구현된 동작으로 암호화 작업을 수행할 때 프로그램이 잘못된 데이터(암호화해야하는 데이터 제외)를 암호화하는 경우일 수 있다.
이러한 제한되지 않은 동작, 그리고 잘못 구현된 동작을 기반으로 보안 취약점을 탐지하는 본 발명의 보안 설계 결함 탐지 장치(100)는 개발자가 구현한 시스템의 단위 테스트 케이스를 기반으로 복잡하고 모호한 테스트 케이스를 자동으로 생성할 수 있으며, 일반적으로 단위 테스트 케이스는 오류를 만드는 코드가 아니라 예상대로 올바르게 작동해야하는 코드를 포함할 수 있다.
따라서 본 발명의 소프트웨어 시스템에서 취약점을 탐지하기 위한 보안 설계 결함 탐지 장치(100)는 자동으로 생성되는 테스트 케이스를 통해 대상 소프트웨어 시스템에서 정의되지 않고 잘못 구현된 동작을 탐지할 수 있다.
이를 위해 보안 설계 결함 탐지 장치(100)는 보안 설계 결함 탐지 방법을 수행하기 위한 소프트웨어(어플리케이션)가(이) 설치되어 실행될 수 있고, 전처리부(110), 보안 정책 테스트부(130), 테스트 케이스 생성부(150) 및 취약점 탐지부(170)를 포함하여 마련될 수 있다.
전처리부(110)는 외부 장치에 저장되어 있는 소프트웨어 시스템에 대해 개발자가 사전에 구현한 코드인 단위 테스트 케이스를 외부 장치로부터 수집하고, 수집된 단위 테스트 케이스를 전처리할 수 있다. 여기서 전처리는 수집된 단위 테스트 케이스에 포함된 코드 조각을 분류하고, 분류된 코드 조각을 조합 또는 변경하여 단위 테스트 케이스를 전처리하는 것일 수 있다. 이를 위해 전처리부(110)는 수집기(Crawler)(111), 분류기(Classifier)(113) 및 분석기(parser)(115)를 포함하여 마련될 수 있다.
수집기(111)는 네트워크를 통해 웹 페이지 등을 포함하는 공식 저장소와 같은 외부 장치에서 대상 소프트웨어 시스템에 대한 단위 테스트 케이스를 수집할 수 있으며, 일반적으로 대부분의 소프트웨어 시스템에는 각 기능을 테스트하기 위한 기본 코드 조각(snippets)인 단위 테스트 케이스가 포함되어 있다.
그리고 수집기(111)는 단위 테스트 케이스를 수집한 후 해당 정보를 사용해야하므로 해당 코드, 즉 단위 테스트 케이스가 있는 URL 및 소스 저장소 내부에 저장된 경로와 같은 코드 출처에 대한 정도도 함께 수집할 수 있다. 예를 들어 "https://github.com/ros/ros_tutorials/tree/noetic-devel/rospy_tutorials/001_talker_listener/talker.py"를 통해 코드 템플릿을 가져왔다고 가정하면, 이 경우 해당 코드 템플릿이 ROS의 noetic 버전을 대상으로 하고 있으며 talker의 관점에서 talker와 listener 간의 기능을 테스트하기 위한 단위 테스트임을 URL에서 알 수 있다.
한편 분류기(113)는 수집기(111)에서 수집된 코드 조각을 클래스, 함수, 주석 및 변수 등으로 분류할 수 있다. 그리고 분류된 코드 조각은 분석기(115)로 전달될 수 있다.
한편 분석기(115)는 대상 소프트웨어 시스템의 제한되지 않고 잘못 구현된 동작을 발견하기 위한 테스트 케이스를 생성하기 위해 분류기(113)에서 분류된 데이터인 코드 조각, 즉 단위 테스트 케이스를 조합하거나 변경할 수 있다.
여기서 분석기(115) 각 단위 테스트 케이스의 논리적 흐름이나 의미를 분석하기보다는 직관적으로 인식할 수 있는 각 단위 테스트 케이스의 기능을 수정하여 전처리함으로써 대상 소프트웨어 시스템의 동작을 식별할 수 있도록 한다. 예를 들어 단위 테스트 케이스에서 특정 변수를 사용하여 함수를 호출하면 분석기(115)는 해당 함수를 호출하는 테스트 케이스를 생성하여 변수의 값을 임의로 수정할 수 있다. 대상 소프트웨어 시스템의 의도된 함수를 표시하기 위해 각 단위 테스트 케이스의 주석도 사용자에게 제공할 수 있다. 이러한 정보를 기반으로 사용자는 대상 소프트웨어 시스템 또는 단위 테스트 케이스를 수동으로 분석하지 않고도 대상 소프트웨어 시스템의 의도된 기능을 찾을 수 있다.
이 때 분석기(115)는 테스트 중인 기능을 설명하기 위한 적절한 설명이 없는, 제대로 개발되지 않은 단위 테스트 사례에서는 사용자에게 충분한 정보를 제공할 수 없기 때문에, 이 경우 분석기(115)는 기능명이나 단위 테스트 케이스 등의 정보만을 사용자에게 제공하도록 할 수 있다.
이렇게 분석기(115)에서 단위 테스트 케이스가 조합 또는 변경된 데이터인 전처리된 단위 테스트 케이스는 보안 정책 테스트부(130)로 전달될 수 있다.
한편 보안 정책 테스트부(130)는 전처리부(110)에서 전처리된 단위 테스트 케이스를 이용해 대상 소프트웨어 시스템이 보안 정책에 위배되는지를 테스트하여 제1 테스트 케이스(TC1)를 생성할 수 있다. 실제로 모든 보안 정책은 시스템 기능과 밀접하게 연결되어 있으며, 기능 테스트에는 많은 보안 메커니즘 실행이 포함된다.
하지만 개발자에 의해 구현된 테스트 기능은 테스트 보안 측면을 고려하지 않지만 보안 취약성은 애플리케이션의 가용성에 영향을 미칠 수 있기 때문에, 보안 정책은 보안 메커니즘에 대한 충분한 신뢰를 제공할 수 있다.
대부분의 경우 보안 정책의 배포는 자동화되지 않기 때문에 구현의 정확성을 확인하거나 테스트 해야하는데, 이러한 맥락에서 본 발명의 보안 정책 테스트부(130)에서 수행되는 보안 정책 테스트를 통해 해당 소프트웨어 시스템에 요구되는 보안 정책에 대한 보안 정책의 구현이 정확하다는 증거를 얻을 수 있게 된다.
따라서 본 발명에 따른 보안 정책 테스트부(130)는 전처리된 단위 테스트 케이스를 사용하여 대상 소프트웨어 시스템의 보안 관점에서 발생할 수 있는 보안 정책을 보여줄 수 있고, 이에 사용자는 보안 정책을 통해 대상 소프트웨어 시스템이 제대로 구현되었는지 이해하고 확인할 수 있게 된다.
대상 소프트웨어 시스템에서 보안 정책을 적용하는 범주는 매우 다양한데, 본 실시예에 따른 보안 설계 결함 탐지 장치(100)에서는 시스템의 특성 중 데이터 전송 보안에 중점을 두고 제한되지 않고 잘못 구현된 동작에서 발생할 수 있는 보안 문제를 사전에 예방하도록 할 수 있다.
데이터 보안 정책은 접근 권한이 있는 사용자와 개체의 각 사용자에게 허용되는 작업 유형을 결정하게 되며, 이에 기초하여 본 발명의 보안 정책 테스트부(130)는 액세스 제어 검사기(131), 무결성 검증기(133) 및 데이터 기밀유지기(135)를 포함하여 마련될 수 있다.
먼저, 액세스 제어 검사기(131)는 전처리된 단위 테스트 케이스에 대한 접근 제어 검사를 통해 권한 부여 여부를 확인하는 제1 보안 정책 테스트를 수행할 수 있다. 액세스 제어 검사기(131)는 대상 소프트웨어 시스템의 기능에 대한 역할 기반 접근 액세스, 사용자 액세스 권한 및 기능 분할과 같은 세부 보안 또는 권한 부여 기능을 식별할 수 있다. 따라서 액세스 제어 검사기(131)는 대상 소프트웨어 시스템에서 동작하는 관리자 권한 및 권한 승격과 같은 기능도 제어를 통해 권한을 부여 받았는지 여부를 확인하는 제1 보안 정책 테스트를 수행할 수 있다.
데이터 무결성 검증기(133)는 전처리된 단위 테스트 케이스에 대한 무결성 검사를 통해 데이터의 무단 변경 또는 변조 여부를 확인하는 제2 보안 정책 테스트를 수행할 수 있다. 데이터는 무단 변경 또는 변조로부터 보호되어야 하는데, 데이터 무결성은 누군가가 권한이 없는 정보를 가로채고 변경하는 조작의 보안 위험으로부터 보호할 수 있다. 이러한 데이터 무결성은 네트워크 내에 저장된 데이터를 보호하는 것 외에도 신뢰할 수 없는 데이터가 시스템에 전송될 때 데이터 무결성을 보장하기 위해 추가적인 보안 요소가 필요하다. 시스템에 입력되는 데이터가 공용 네트워크에서 수신되는 경우, 일반적으로 암호화하여 데이터가 스니핑 및 해석되지 않도록 보호되어야 하며 데이터가 변경되지 않았는지 확인하여야 한다. 이를 위해 데이터 무결성 검증기(133)는 데이터의 변경 또는 변조 여부를 확인하는 제2 보안 정책 테스트를 수행할 수 있다.
한편 데이터 기밀유지기(135)는 전처리된 단위 테스트 케이스에 대한 기밀유지 검사를 통해 데이터의 암호화여부를 확인하는 제3 보안 정책 테스트를 수행할 수 있다. 데이터 기밀유지는 정보를 오직 인가된 사용자에게만 공개하는 것을 의미하는 것으로, 전송되는 데이터의 내용을 완벽하게 보호해 인가되지 않은 사용자, 즉 비인가자가 정보의 실제 내용에 접근하는 것을 방지하는 것이다. 비밀보장이 되며 원치않는 정보의 공개를 막을 수 있는 기밀유지는 주로 데이터 하이재킹(Hijacking)에 관한 행위로부터 데이터를 보호할 수 있으며, 가장 대중적인 사용방법인 암호화를 사용하는지에 대한 여부를 확인할 수 있다. 데이터 기밀유지기(135)는 이러한 데이터의 암호화여부를 확인하는 제3 보안 정책 테스트를 수행할 수 있다.
이 때 보안 설계 결함 탐지 장치(100)는 액세스 제어 검사기(131)에서 수행되는 제1 보안 정책 테스트, 데이터 무결성 검증기(133)에서 수행되는 제2 보안 정책 테스트 및 데이터 기밀유지기(135)에서 수행되는 제3 보안 정책 테스트가 기설정된 순서에 따라 수행되도록 할 수 있다. 이러한 기설정된 순서는 보안 설계 결함 탐지 장치(100)를 사용하는 시스템 개발자가 설정한 순서일 수 있으며, 보안 정책 테스트부(130)는 제1 내지 제3 보안 정책을 설정된 순서에 따라 순차적으로 수행할 수 있다. 도 4에서는 데이터 기밀유지기(135)에서 수행되는 제3 보안 정책 테스트가 마지막에 수행되는 것으로 도시되었으나, 이는 설명의 편의를 위한 예시적 사항일 뿐, 이에 한정되는 것은 아니다.
그리고 모든 보안 정책 테스트가 완료된 전처리 단위 테스트 케이스인 제1 테스트 케이스(TC1)는 보안 정책 테스트의 결과와 함께 테스트 케이스 생성부(150)로 전달될 수 있다. 이러한 제1 테스트 케이스(TC1)에는 보안 정책 테스트에 대한 결과가 함께 포함될 수도 있다.
한편, 테스트 케이스 생성부(150)는, 보안 정책 테스트부(130)로부터 전달받은 제1 테스트 케이스(TC1)에 기초하여 대상 소프트웨어 시스템의 기능을 테스트하기 위한 데이터 집합인 제2 테스트 케이스(TC2)를 생성할 수 있다.
이 때 테스트 케이스 생성부(150)를 이용해 제2 테스트 케이스(TC2)를 생성함에 있어 대상 소프트웨어 시스템에서 위배될 수 있는 보안 정책을 제1 테스트 케이스(TC1)에 적용하여 제2 테스트 케이스를 생성할 수도 있다.
또한 테스트 케이스 생성부(150)는 제한되지 않고 잘못 구현된 동작을 발견할 가능성을 극대화하기 위해 대상 소프트웨어 시스템의 특정 기능한 테스트할 수 있는 제2 테스트 케이스(TC2)를 생성하기보다는 한 번에 다양한 기능을 테스트할 수 있는 제2 테스트 케이스(TC2)를 도 5 및 도 6과 같이 생성하도록 하는 것이 바람직할 수 있으며, 이를 위해 본 테스트 케이스 생성부(150)는 무작위 생성기(151) 및 결합 생성기(153)를 포함할 수 있다.
무작위 생성기(R.A.G)(151)는 제1 테스트 케이스를 무작위로 생성된 데이터 유형 및 값으로 조작하여 상기 제2 테스트 케이스를 생성할 수 있다. 구체적으로 무작위 생성기(151)는 제1 테스트 케이스(TC1)에 포함된 코드 조각을 무작위로 생성된 데이터 유형 및 값으로 변경하여 단위 테스트 케이스 내부의 값(데이터)를 조작함으로써 제2 테스트 케이스(TC2)를 단일 단위 테스트 케이스로 생성할 수 있다.
한편, 결합 생성기(153)는 전처리되지 않은 단위 테스트 케이스를 제1 테스트 케이스(TC1)에 결합하여 상기 제2 테스트 케이스(TC2)를 생성할 수 있다.
구체적으로 결합 생성기(153)는 수집기(111)에서 수집된 단위 테스트 케이스, 즉 분석기(115)를 통한 전처리가 되지 않은 복수의 단위 테스트 케이스를 제1 테스트 케이스(TC1)에 결합하는 방식으로 제2 테스트 케이스(TC2)를 생성할 수 있다.
이 때 제1 테스트 케이스(TC1)에 결합되는 전처리되지 않은 단위 테스트 케이스의 개수는 임의로 결정되거나 사전에 설정된 개수에 따라 정해질 수 있다. 또한 결합 생성기(153)는 사용자가 제1 테스트 케이스(TC1)에 결합될 단위 테스트 케이스를 특정하도록 할 수도 있다.
한편 취약점 탐지부(170)는 무작위 생성기(151) 또는 결합 생성기(153)를 통해 생성된 제2 테스트 케이스(TC2)를 실행하여 시스템의 취약점을 탐지할 수 있다.
본 발명의 일 실시예에 따른 보안 설계 결함 탐지 장치(100)는 도면에는 미도시하였으나, 단위 테스트 케이스를 포함하여 필요한 각종 정보를 수집 또는 입력받기 위한 통신부 또는 입력부는 물론, 수집된 단위 테스트 케이스를 전처리하고, 이를 분석하여 테스트 케이스를 생성하기 위해 필요한 각종 정보를 저장하는 저장부 및 결과물을 출력할 수 있는 출력부를 포함할 수 있다.
이하에서는 본 발명의 일 실시예에 따른 보안 설계 결함 탐지 장치(100)의 효과를 확인하기 위해 수행한 정량적, 정성적 평가 결과에 대해 설명하기로 한다. 본 실시예에 따른 보안 설계 결함 탐지 장치(100)의 효과를 검증하기 위해 3.40GHz Intel Skylake processor와 16GB RAM이 탑재된 Ubuntu Linux 14.06 64비트를 실행하는 시스템에서 평가가 수행되었고, 다양한 버전의 로봇 운영 체제(ROS, Robot Operating System)에 대한 취약점을 발견하기 위해 본 발명의 보안 설계 결함 탐지 장치(100)를 사용하였다.
여기서 ROS는 로봇 공학을 위한 오픈 소스 메타 운영 체제(소프트웨어 프레임워크 모음)으로, 현재 ROS는 많은 학술 프로젝트 및 상용 제품에 사용되고 있다. ROS는 하드웨어 추상화, 저수준 장치 제어, 일반 운영체제에서 제공하는 자주 사용하는 기능을 구현하고, 프로세스 간 메시지 전달 및 패키지 관리 기능을 제공할 수 있다. 또한 여러 시스템에서 작업할 수 있는 도구와 라이브러리를 제공하며 분산 계산, 멀티 스레딩(multi threading), 이벤트 기반 프로그래밍 및 기타 시스템 핵심 개념을 포함하여 상당한 수준의 복잡성을 가지고 있다.
이러한 ROS는 노드 간의 메시지 통신을 통해 진행하고, 노드는 시작 시 마스터에 정보를 등록해야 한다. 그리고 마스터는 각 노드의 정보를 가지고 있으며 노드를 관리하는 중요한 역할을 한다. 하지만 마스터도 실패할 수 있으며, 마스터에서 제한되지 않거나 잘못 구현된 동작이 발생하면 전체 시스템에 부정적인 영향을 미칠 수 있다. CVE-2016-10681을 비롯한 원격 모드 실행 취약점은 로봇의 대표적인 메타 OS인 ROS에서도 발견되었고, ROS에서 제공하는 계산 그래프 패키지의 설계 결함으로 인해 많은 MiR 로봇이 취약점에 노출되었다.
평가를 위해 최초 출시된 BOX Turtle 버전과 가장 최근에 출시된 ROS Noetic Nunjemys 버전부터 13가지 버전의 ROS를 테스트하였다. ROS에는 기본 기능, 서비스 및 노드 간의 상호 작용을 확인하기 위해 설계된 여러 단위 테스트 케이스가 있으며, 본 발명의 보안 설계 결함 탐지 장치(100)를 사용하여 이러한 ROS에서 제한되지 않거나 잘못 구현된 동작을 발견하기 위한 테스트 케이스를 생성하였다.
ROS에서 제한되지 않고 잘못 구현된 동작을 기반으로 취약점을 탐지하기 위해 본 실시예에 따른 보안 설계 결함 탐지 장치(100)를 사용해 테스트 케이스로 퍼지 테스트 케이스(fuzzy test cases)를 생성하고, ROS에서 실행하여 모니터링하였다.
먼저 보안 설계 결함 탐지 장치(100)는 공식 소스 코드 저장소와 ROS의 웹 커뮤니티에서 113개의 단위 테스트 케이스를 수집하였다. 그 다음 취약점 발견을 위한 테스트 케이스를 생성하였는데, 도 5 및 도 6은 보안 설계 결함 탐지 장치(100)에서 생성된 테스트 케이스의 코드 조각을 보여주는 도면이다. 각 도면에서와 같이 보안 설계 결함 탐지 장치(100)는 각 테스트 케이스에서 평가되는 모듈에 대한 간략한 설명을 함께 사용자에게 제공할 수 있다.
평가 결과 본 발명의 보안 설계 결함 탐지 장치(100)는 생성한 수 많은 테스트 코드에서 ROS의 XMLRPC 모듈과 TCPROS 모듈에서 제한되지 않은 동작과 잘못 구현된 동작을 식별하여 취약점을 탐지하였다. 또한 최초 공개된 ROS 버전부터 최신 버전까지 탐지된 취약점이 악용될 수 있음을 확인하였다.
먼저 XMLRPC 모듈에서의 제한되지 않은 무제한 동작에 대해 설명하기로 한다. 도 7은 상술한 바와 같이 마스터에 노드의 새로운 정보를 등록하는 과정을 도시한 도면으로, 동일한 이름의 listener를 등록하는 테스트 케이스를 실행하여 무제한 동작을 탐지하였다. ROS에서는 Talker 노드와 Listener 노드가 마스터 노드에 등록되어 있어야 서로 통신이 가능하다. 도 5에서는 "listener"라는 이름의 노드가 처음에 마스터에 등록되고, "listener"라는 이름의 다른 노드가 마스터에 등록 요청을 보내는데, 테스트 케이스를 통해 이전에 등록된 "listener"노드가 등록 취소되고 있음을 발견하였다.
해당 취약점의 근본 원인을 수동으로 분석한 결과, 마스터 노드에서 노드(예:talker와 listener) 간의 연결을 시작하는 데 사용되는 XMLRPC 통신 모듈에서 문제를 발견하였다. 마스터 노드가 Talker 및 Talker가 되고자 하는 노드로부터 요청을 받았을 때 마스터는 해당 노드를 listener 또는 Talker로 등록하기 위한 인증 절차를 수행하지 않았다.
도 7은 XMLRPC 모듈에 새 노드를 등록하는 코드 조각을 보여주는데, 노드에서 등록 요청이 오면 노드 주소에 해당하는 API 값만 확인할 뿐, 이전 API값과 요청된 API값이 다른 경우 XMLRPC 모듈은 추가 확인 없이 요청된 API를 bumped_api로 설정한다. 따라서 기존에 등록된 노드와 이름이 같은 새로운 노드가 listener를 요청하면 기존에 운영하던 서비스는 취소되고 새로운 연결이 시작되고, 결과적으로 ROS에서 악의적인 노드는 listener가 되어 두 노드 간의 데이터 트래픽을 가로챌 수 있음을 보여준다.
한편 이하에서는 상술한 TCPROS 모듈에서의 잘못 구현된 동작에 대해 설명하기로한다. 도 8은 ROS에서 사용되는 md5sum 및 문자열 메시지 유형 코드를 확인하는 도면이다. 도 6에 도시된 테스트 케이스, 즉 보안 설계 결함 탐지 장치(100)에서 생성된 제2 테스트 케이스는, 무작위로 생성된 인수를 talker 노드로 보내는 테스트 케이스이다. 해당 테스트 케이스를 실행하고 실행 결과를 모니터링한 결과 ROS에서 잘못 구현된 동작을 발견하였는데, 메시지 무결성 검사를 위한 해시 함수가 제대로 사용되지 않았다.
ROS에서 TCPROS 모듈은 TCP/IP를 기반으로 메시지 및 서비스를 전송하는데 사용되는 것으로, TCPROS 모듈에 의해 전송되는 모든 메시지의 메시지 헤더에는 메시지의 무결성을 확인하기 위한 md5sum필드가 있다. 하지만 TCPROS 모듈에서는 메시지의 무결성을 확인하는 기능이 세심하게 구현되지 않았음을 확인하였다. 구체적으로 도 8은 TCPROS 모듈에서 md5sum 해시를 사용하는 함수를 보여주는데, 함수에서 메시지의 실제 데이터를 포함하는 메시지 본문을 해시하는 대신 메시지 유형만 해시하여 md5sum을 생성한다. 따라서 메시지가 달라도 메시지의 md5sum 값이 동일하게 되고, 그 결과 ROS에서는 검증 과정을 거치지 않고 각각의 메시지를 위조하는 것이 가능한 취약점을 가지게 된다.
보안 설계 결함 탐지 장치(100)가 발견할 수 있는 취약점 유형을 평가하였으며, 이 평가는 보안 설계 결함 탐지 장치(100)가 취약점을 탐지하는 데 도움이 될 수 있는 특정 범위를 제공하는 것으로, 실험 결과 본 발명에 따른 보안 설계 결함 탐지 장치(100)가 탐지할 수 있는 취약점의 유형은 도 9에 도시된 바와 같다. 도면에서 체크 표시(v)는 탐지 가능한 취약점 유형을 나타낸다.
도 9를 참조하여 설명하면, 코드 인젝션 취약점(Code Injection Vulnerability)은 악성 코드가 시스템에 삽입되어 페이로드를 작성하여 실행될 수 있는 것으로, 이러한 취약점을 프로그램이 입력 값을 적절하게 제한하거나 확인하지 않을 때 존재한다. 따라서 보안 설계 결함 탐지 장치(100)는 이러한 취약점을 유발하는데 사용되는 사전 정의된 값 또는 기호를 사용하여 테스트 케이스를 생성할 수 있다.
데이터 유효성 검증 취약점(Data Validation Vulnerability)은 데이터 유형을 검증하는 기증이 잘못 구현될 때 발생하는 것으로, 본 실시예에 따른 보안 설계 결함 탐지 장치(100)는 제2 테스트 케이스로 의도적으로 대상 소프트웨어 시스템에 대해 데이터 유형의 부적절한 사용을 유발하는 테스트 케이스를 생성할 수 있고, 임의의 순서로 여러 임의 기능을 실행하는 테스트 케이스를 생성할 수도 있다. 이러한 테스트 케이스는 데이터 구조에 대해 구현되지 않은 임의의 기능이 있는 데이터 구조를 사용하거나 조작할 수 있기 때문에 데이터 유효성 검사 취약성 유형을 발견하는데 사용할 수 있다.
한편 예외 처리(Exception Handling) 유형의 취약점은 시스템에 구현된 적절한 예외 처리 기능이 없을 때 존재하는데, 예외 처리기가 시스템에 구현되지 않은 경우 예외가 충돌하거나 다른 취약점으로 이어질 수 있다. 따라서 본 보안 설계 결함 탐지 장치(100)는 다양한 데이터를 사용하는 테스트 케이스와 시스템의 다양한 기능 간의 상호 작용을 테스트할 수 있는 제2 테스트 케이스를 생성하여 제공할 수 있다. 이러한 제2 테스트 케이스는 시스템에서 예외를 유발할 수 있으며, 이는 예외 처리와 관련된 취약점을 감지하는 데 도움이 될 수 있다.
요약하면, 도 9는 본 실시예에 따른 보안 설계 결함 탐지 장치(100)가 코드 삽입, 데이터 검증, 예외 처리 유형의 취약점을 탐지할 수 있다. 따라서 기존의 메모리 취약성을 발견하는데 그치는 취약점 탐지 장치와는 달리, 본 발명의 보안 설계 결함 탐지 장치(100)는 보안 설계 결함으로 인한 취약점을 탐지하는데 효과적임을 알 수 있다.
한편, 도 10은 본 발명의 일 실시예에 따른 보안 설계 결함 탐지 방법을 설명하기 위한 흐름도로써, 본 발명의 일 실시예에 따른 보안 설계 결함 탐지 방법은 도 3 및 도 4에 도시된 소프트웨어 시스템에 대한 보안 설계 결함을 탐지하기 위한 보안 설계 결함 탐지 장치(100)와 실질적으로 동일한 구성 상에서 진행되므로, 도 3 및 도 4의 보안 설계 결함 탐지 장치(100)와 동일한 구성요소에 대해 동일한 도면 부호를 부여하고, 반복되는 설명은 생략하기로 한다.
먼저 보안 설계 결함 탐지 장치(100)는, 외부 장치로부터 소프트웨어 시스템에 대한 단위 테스트 케이스를 수집하고, 단위 테스트 케이스를 전처리할 수 있다(S110).
이러한 전처리하는 단계(S110)에서는, 단위 테스트 케이스에 포함된 코드 조각을 분류하고, 분류된 코드 조각에 기초하여 단위 테스트 케이스를 조합 또는 변경하여 전처리하는 것일 수 있다.
이후 전처리된 단위 테스트 케이스를 이용해 소프트웨어 시스템이 보안 정책에 위배되는지 테스트하여 제1 테스트 케이스를 생성하는 단계를 수행할 수 있다(S130).
제1 테스트 케이스를 생성하는 단계(S130)는, 전처리된 단위 테스트 케이스에 대한 접근 제어 검사를 통해 권한 부여 여부를 확인하는 제1 보안 정책 테스트를 수행하는 단계(미도시), 전처리된 단위 테스트 케이스에 대한 무결성 검사를 통해 데이터의 무단 변경 또는 변조 여부를 확인하는 제2 보안 정책 테스트를 수행하는 단계(미도시), 그리고 전처리된 단위 테스트 케이스에 대한 기밀유지 검사를 통해 데이터의 암호화여부를 확인하는 제3 보안 정책 테스트를 수행하는 단계(미도시)를 포함할 수 있다.
그리고 이러한 제1 보안 정책 테스트를 수행하는 단계(미도시), 제2 보안 정책 테스트를 수행하는 단계(미도시) 및 제3 보안 정책 테스트를 수행하는 단계(미도시)는 사전에 설정된 순서에 따라 수행될 수 있다.
이후 제1 테스트 케이스에 기초하여 상기 소프트웨어 시스템의 기능을 테스트하기 위한 데이터 집합인 제2 테스트 케이스를 생성하는 단계를 수행할 수 있다(S150).
제2 테스트 케이스를 생성하는 단계(S150)에서는, 제1 테스트 케이스를 무작위로 생성된 데이터 유형 및 값으로 조작하여 제2 테스트 케이스를 생성하거나, 전처리되지 않은 단위 테스트 케이스를 제1 테스트 케이스에 결합하여 제2 테스트 케이스를 생성할 수도 있다.
그리고나서 제2 테스트 케이스를 실행하여 상기 소프트웨어 시스템의 취약점을 탐지하는 단계를 수행할 수 있다(S170).
이와 같은 본 발명의 보안 설계 결함 탐지 방법은 다양한 컴퓨터 구성요소를 통하여 수행될 수 있는 프로그램 명령어의 형태로 구현되어 컴퓨터 판독 가능한 기록 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능한 기록 매체는 프로그램 명령어, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다.
상기 컴퓨터 판독 가능한 기록 매체에 기록되는 프로그램 명령어는 본 발명을 위하여 특별히 설계되고 구성된 것들이거니와 컴퓨터 소프트웨어 분야의 당업자에게 공지되어 사용 가능한 것일 수도 있다.
컴퓨터 판독 가능한 기록 매체의 예에는, 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체, CD-ROM, DVD 와 같은 광기록 매체, 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 ROM, RAM, 플래시 메모리 등과 같은 프로그램 명령어를 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다.
프로그램 명령어의 예에는, 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드도 포함된다. 상기 하드웨어 장치는 본 발명에 따른 처리를 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.
이상에서는 본 발명의 다양한 실시예에 대하여 도시하고 설명하였지만, 본 발명은 상술한 특정의 실시예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해되어져서는 안될 것이다.
[부호의 설명]
100 : 보안 설계 결함 탐지 장치 110 : 전처리부
111 : 수집기 113 : 분류기
115 : 분석기 130 : 보안 정책 테스트부
131 : 액세스 제어 검사기 133 : 데이터 무결성 검증기
135 : 데이터 기밀유지기 150 : 테스트 케이스 생성부
151 : 무작위 생성기 153 : 결합 생성기
170 : 취약점 탐지부

Claims (11)

  1. 소프트웨어 시스템에 대한 보안 설계 결함을 탐지하기 위한 보안 설계 결함 탐지 장치에서 수행되는 단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법에 있어서,
    외부 장치로부터 상기 소프트웨어 시스템에 대한 단위 테스트 케이스를 수집하고, 상기 단위 테스트 케이스를 전처리하는 단계;
    전처리된 단위 테스트 케이스를 이용해 상기 소프트웨어 시스템이 보안 정책에 위배되는지 테스트하여 제1 테스트 케이스를 생성하는 단계;
    상기 제1 테스트 케이스에 기초하여 상기 소프트웨어 시스템의 기능을 테스트하기 위한 데이터 집합인 제2 테스트 케이스를 생성하는 단계; 및
    상기 제2 테스트 케이스를 실행하여 상기 소프트웨어 시스템의 취약점을 탐지하는 단계를 포함하는, 단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법.
  2. 제1항에 있어서,
    상기 전처리하는 단계에서는,
    상기 단위 테스트 케이스에 포함된 코드 조각을 분류하고, 분류된 코드 조각에 기초하여 상기 단위 테스트 케이스를 조합 또는 변경하여 전처리하는 것을 특징으로 하는, 단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법.
  3. 제1항에 있어서,
    상기 제1 테스트 케이스를 생성하는 단계는,
    상기 전처리된 단위 테스트 케이스에 대한 접근 제어 검사를 통해 권한 부여 여부를 확인하는 제1 보안 정책 테스트를 수행하는 단계;
    상기 전처리된 단위 테스트 케이스에 대한 무결성 검사를 통해 데이터의 무단 변경 또는 변조 여부를 확인하는 제2 보안 정책 테스트를 수행하는 단계; 및
    상기 전처리된 단위 테스트 케이스에 대한 기밀유지 검사를 통해 데이터의 암호화여부를 확인하는 제3 보안 정책 테스트를 수행하는 단계를 포함하는 것을 특징으로 하는, 단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법.
  4. 제3항에 있어서,
    상기 제1 보안 정책 테스트를 수행하는 단계, 제2 보안 정책 테스트를 수행하는 단계 및 제3 보안 정책 테스트를 수행하는 단계는, 기설정된 순서에 따라 수행되는 것을 특징으로 하는, 단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법.
  5. 제1항에 있어서,
    상기 제2 테스트 케이스를 생성하는 단계에서는,
    상기 제1 테스트 케이스를 무작위로 생성된 데이터 유형 및 값으로 조작하여 상기 제2 테스트 케이스를 생성하거나, 전처리되지 않은 상기 단위 테스트 케이스를 상기 제1 테스트 케이스에 결합하여 상기 제2 테스트 케이스를 생성하는 것을 특징으로 하는, 단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법.
  6. 제1항에 따른 상기 단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법을 수행하기 위한 컴퓨터 프로그램이 기록된 컴퓨터로 판독 가능한 저장 매체.
  7. 소프트웨어 시스템에 대한 보안 설계 결함을 탐지하기 위한 단위 테스트 케이스 기반의 보안 설계 결함 탐지 장치에 있어서,
    외부 장치로부터 상기 소프트웨어 시스템에 대한 단위 테스트 케이스를 수집하고, 상기 단위 테스트 케이스를 전처리하는 전처리부;
    전처리된 단위 테스트 케이스를 이용해 상기 소프트웨어 시스템이 보안 정책에 위배되는지 테스트하여 제1 테스트 케이스를 생성하는 보안 정책 테스트부;
    상기 제1 테스트 케이스에 기초하여 상기 소프트웨어 시스템의 기능을 테스트하기 위한 데이터 집합인 제2 테스트 케이스를 생성하는 테스트 케이스 생성부; 및
    상기 제2 테스트 케이스를 실행하여 상기 소프트웨어 시스템의 취약점을 탐지하는 취약점 탐지부를 포함하는, 단위 테스트 케이스 기반의 보안 설계 결함 탐지 장치.
  8. 제7항에 있어서,
    상기 전처리부는,
    상기 단위 테스트 케이스에 포함된 코드 조각을 분류하고, 분류된 코드 조각에 기초하여 상기 단위 테스트 케이스를 조합 또는 변경하여 전처리하는 것을 특징으로 하는, 단위 테스트 케이스 기반의 보안 설계 결함 탐지 장치.
  9. 제7항에 있어서,
    상기 보안 정책 테스트부는,
    상기 전처리된 단위 테스트 케이스에 대한 접근 제어 검사를 통해 권한 부여 여부를 확인하는 제1 보안 정책 테스트를 수행하는 액세스 제어 검사기;
    상기 전처리된 단위 테스트 케이스에 대한 무결성 검사를 통해 데이터의 무단 변경 또는 변조 여부를 확인하는 제2 보안 정책 테스트를 수행하는 데이터 무결성 검증기; 및
    상기 전처리된 단위 테스트 케이스에 대한 기밀유지 검사를 통해 데이터의 암호화여부를 확인하는 제3 보안 정책 테스트를 수행하는 데이터 기밀유지기를 포함하는 것을 특징으로 하는, 단위 테스트 케이스 기반의 보안 설계 결함 탐지 장치.
  10. 제9항에 있어서,
    상기 제1 보안 정책 테스트, 제2 보안 정책 테스트 및 제3 보안 정책 테스트는 기설정된 순서에 따라 수행되는 것을 특징으로 하는, 단위 테스트 케이스 기반의 보안 설계 결함 탐지 장치.
  11. 제7항에 있어서,
    테스트 케이스 생성부는,
    상기 제1 테스트 케이스를 무작위로 생성된 데이터 유형 및 값으로 조작하여 상기 제2 테스트 케이스를 생성하는 무작위 생성기; 및
    전처리되지 않은 상기 단위 테스트 케이스를 상기 제1 테스트 케이스에 결합하여 상기 제2 테스트 케이스를 생성하는 결합 생성기를 포함하는 것을 특징으로 하는, 단위 테스트 케이스 기반의 보안 설계 결함 탐지 장치.
PCT/KR2022/015342 2021-11-25 2022-10-12 단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법, 이를 수행하기 위한 기록 매체 및 장치 WO2023096152A1 (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR20210164903 2021-11-25
KR10-2021-0164903 2021-11-25
KR10-2022-0000934 2022-01-04
KR1020220000934A KR102470683B1 (ko) 2021-11-25 2022-01-04 단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법, 이를 수행하기 위한 기록 매체 및 장치

Publications (1)

Publication Number Publication Date
WO2023096152A1 true WO2023096152A1 (ko) 2023-06-01

Family

ID=84237275

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2022/015342 WO2023096152A1 (ko) 2021-11-25 2022-10-12 단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법, 이를 수행하기 위한 기록 매체 및 장치

Country Status (2)

Country Link
KR (1) KR102470683B1 (ko)
WO (1) WO2023096152A1 (ko)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080068385A (ko) * 2007-01-19 2008-07-23 슈어소프트테크주식회사 소프트웨어 테스트 시스템, 방법 및 그 방법을 실행하기위한 프로그램이 기록된 컴퓨터로 읽을 수 있는 기록매체
US20120198280A1 (en) * 2011-01-28 2012-08-02 International Business Machines Corporation Test cases generation for different test types
KR101320264B1 (ko) * 2011-09-09 2013-10-23 (주)엠젠 웹 기반의 소프트웨어 개발 및 테스트 자동화 장치
KR101704338B1 (ko) * 2016-02-12 2017-02-08 강원대학교산학협력단 실시간 시스템을 위한 테스트 케이스 생성 장치 및 방법
KR20190113680A (ko) * 2018-03-28 2019-10-08 주식회사 테스트웍스 웹 페이지의 테스트 케이스 생성 방법 및 장치
KR20210061893A (ko) * 2019-11-20 2021-05-28 한국전자통신연구원 소프트웨어 취약점 검출 장치 및 방법

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101134735B1 (ko) * 2010-11-03 2012-04-13 재단법인대구경북과학기술원 소프트웨어 컴포넌트 설계정보를 이용한 소프트웨어 테스트 방법 및 시스템
KR101706425B1 (ko) * 2014-10-15 2017-02-13 삼성에스디에스 주식회사 코드의 단위 테스트를 위한 장치 및 방법

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080068385A (ko) * 2007-01-19 2008-07-23 슈어소프트테크주식회사 소프트웨어 테스트 시스템, 방법 및 그 방법을 실행하기위한 프로그램이 기록된 컴퓨터로 읽을 수 있는 기록매체
US20120198280A1 (en) * 2011-01-28 2012-08-02 International Business Machines Corporation Test cases generation for different test types
KR101320264B1 (ko) * 2011-09-09 2013-10-23 (주)엠젠 웹 기반의 소프트웨어 개발 및 테스트 자동화 장치
KR101704338B1 (ko) * 2016-02-12 2017-02-08 강원대학교산학협력단 실시간 시스템을 위한 테스트 케이스 생성 장치 및 방법
KR20190113680A (ko) * 2018-03-28 2019-10-08 주식회사 테스트웍스 웹 페이지의 테스트 케이스 생성 방법 및 장치
KR20210061893A (ko) * 2019-11-20 2021-05-28 한국전자통신연구원 소프트웨어 취약점 검출 장치 및 방법

Also Published As

Publication number Publication date
KR102470683B1 (ko) 2022-11-25

Similar Documents

Publication Publication Date Title
Bishop A taxonomy of unix system and network vulnerabilities
Aslam A taxonomy of security faults in the unix operating system
Song et al. An analysis of technical security control requirements for digital I&C systems in nuclear power plants
KR20060076152A (ko) 웹 서비스 구성의 보안 검사 방법
US20060053492A1 (en) Software tracking protection system
WO2019039730A1 (ko) 랜섬웨어 방지 장치 및 방법
Santos et al. An empirical study of tactical vulnerabilities
CN115310084A (zh) 一种防篡改的数据保护方法及系统
US20050038790A1 (en) Device and method for establishing a security policy in a distributed system
Inam et al. Forensic analysis of configuration-based attacks
Malik et al. An empirical study of vulnerabilities in edge frameworks to support security testing improvement
US8336107B2 (en) System and methods for defending against root
WO2023096152A1 (ko) 단위 테스트 케이스 기반의 보안 설계 결함 탐지 방법, 이를 수행하기 위한 기록 매체 및 장치
Jayaram et al. Software engineering for secure software-state of the art: A survey
Ecarot et al. Apparmor for health data access control: Assessing risks and benefits
US20210258331A1 (en) Penetration test monitoring server and system
WO2006040757A1 (en) A system and method for authenticating and validating the linkage between input files and output files in a computational process
WO2024128738A1 (ko) 사이버 보안 위협 및 공격 표면 관리 방법 및 이러한 방법을 수행하는 장치
Dharam et al. Runtime monitoring framework for SQL injection attacks
Levine A methodology for detecting and classifying rootkit exploits
Ma et al. Towards comprehensively understanding the run-time security of programmable logic controllers: A 3-year empirical study
CN116861411B (zh) 基于Seccomp机制的安全沙箱数据保护方法及系统
Basin et al. Logging and log analysis
Polk Automated tools for testing computer system vulnerability
Levine et al. A methodology for detecting new binary rootkit exploits

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22898835

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18550865

Country of ref document: US