Common Criteria Requirement of Data Leakage Protection System

Common Criteria Requirement of Data Leakage Protection System 보안공학연구논문지 Journal of Security Engineering Vol.11, No.1 (2014), pp.65-78 http://dx.doi.org/10.14257/jse.2014.02.10 Hyun-Jung Lee 1), Seung-Eun Jeong 2), Jae-In Shin 3), Kab-Seung Kou 4) Abstract Recently, one of the big issues is secret information leakage from medium and large sized companies as personal information leakage and proprietary information leakage by internal employees are happened repeatedly. The companies which happened the security accident damage as falling stocks and sales, collective damages and these damages effect on management in the companies. Proprietary information leakage is occurred by using the connection such as Internet, e-mail or message service and direct information leakage is occurred by USB or CD. Various methods have been created to protect the proprietary information leakage and finally DLP which is one of the various methods are created. In this paper, we deduce Security functionality which DLP should have for protecting proprietary information leakage as using ISO 14598. Keywords : DLP, Data Leakage Protection, Data Loss Prevention, Protection Profile, Common Criteria 1. Introduction Recent reports show that the number of the cases of personal information stolen or lost is increasing and the scale of damage is growing. The IT Policy Compliance Group says 20% of companies suffer from more than 22 cases of information theft a year. According to the Forrester Research, one of the most famous market analysis companies, direct loss resulting from data leakage costs a non-financial company $15 per each client, which includes expenses for notifying clients, credit monitoring services, IT restoration, decline in sales because of past customers, and legal procedures and audit. In the case of financial companies, such as a credit card company, the expense loss amounts to $50 per each client [3 and 6]. Data of a company(e.g. financial Received(January 09, 2014), Review request(january 10, 2014), Review Result(1st: January 24, 2014, 2nd: February 08, 2014) Accepted(February 28, 2014) 1 138-200 TA Team, Korea System Assurance, Munjeong-dong, Songpa-gu, Seoul, Korea email: hjlee@kosyas.com 2 138-200 TA Team, Korea System Assurance, Munjeong-dong, Songpa-gu, Seoul, Korea email: seung1009@kosyas.com 3 138-200 R&D Team, Korea System Assurance, Munjeong-dong, Songpa-gu, Seoul, Korea email: jaein@kosyas.com 4 (Corresponding Author) 138-200 R&D Team, Korea System Assurance, Munjeong-dong, Songpa-gu, Seoul, Korea email: kabseung@kosyas.com * This research was funded by the MSIP(Ministry of Science, ICT & Future Planning), Korea in the ICT R&D Program 2013 ISSN: 1738-7531 JSE 65 Copyright c 2013 SERSC

Common Criteria Requirement of Data Leakage Protection System document, client data, source code, IPR, etc.) is the company itself. Nevertheless, a few clicks on the mouse can result in the company data leakage, which will damage the company reputation for not observing the industry regulations and even impose a heavy fine on the company. The distinguished Datamonitor report says that more than 60% of respondents have leaked data in the previous year and 33% have answered this could lead to bankruptcy. In Korea, industrial spy crimes related to in-house information leakage increased from 5 cases in 2002 to 41 in 2010 and the scale of damage over the past 6 years approximately hits 133 trillion won. Now people care about the information leakage in the large enterprises more than ever. The prime reason for in-house information leakage is the lack of security awareness of users. It is not easy to control the users, which are fluent as anyone can assume. The best a company can do is to make sure it has a security system infrastructure for internal security. That is why more and more companies are using a DLP solution, which is a kind of document leakage protection solution, to encode documents and minimize damage in case of leakage. This solution monitors and controls possible channels of information leakage like an email or messenger and traces information leakage due to an individual s intended illegal action. It can combine existing solutions and provide more extensive security processes in one step. Information Protection and Control report of the IDC in 2007 estimated that the size of DLP market all over the world would be at 3.2 billion dollars by 2011. A DLP solution has been first introduced in financial and insurance industries with a firm standard in handling clients information, which is understandable considering how it deals with a large amount of major client information. It is now being used in most banks and insurance companies in the U.S. As information is considered a key to a successful business, there are increasing interest and needs for a DLP in many other industries. For example, a manufacturing or high-tech company should protect its information to win the competition; a medical institution should protect the information of patients; and a government institution should protect the information of people and also the confidential information of national defense. Even though the need for a DLP system keeps increasing, there is no standard regarding the security functions required of a DLP system yet, which may lead to a company using a DLP system and still risking information leakage. This paper intends to derive necessary security functions of a DLP system based on the Common Criteria and suggest a baseline of a system that can prevent information leakage. The rest of this paper is organized as follows. In Section 2, we briefly describe the DLP system and protection profile according to common criteria. We review the existing DLP system protection profiles in Section 3. In Section 4, we propose a protection profile for DLP system. To do this, we present the target of evaluation (TOE) and describe security environment, security objectives and derive security requirements of the DLP systems. In Section 5, we analyze our protection profile. Finally, we summarize and conclude in Section 6. 66 Copyright c 2014 SERSC

보안공학연구논문지 Journal of Security Engineering Vol.11, No.1 (2014) 2. Related Works 2.1 CC(common Criteria) and Protection Profile CC(Common Criteria). The CC does so by providing a common set of requirements for the security functionality of IT products and for assurance measures applied to these IT products during a security evaluation[2]. This security evaluation includes the testing and an analysis of the IT products. The evaluation process establishes a level of confidence that the security functionality of these IT products and the assurance measures applied to these IT products meet these requirements[2]. The evaluation results may help consumers to determine whether these IT products fulfill their security needs[2]. Protection Profile. To allow consumer groups and communities of interest to express their security needs, and to facilitate writing STs, the CC provides a special construct called Protection Profile (PP). Whereas an ST always describes a specific TOE, a PP is intended to describe a TOE type (e.g. firewalls). The same PP may therefore be used as a template for many different STs to be used in different evaluations. A PP must contain a PP introduction, conformance claim, security problem definition, security objectives, extended components definition, and security requirements[1 and 2]. 2.2 Extended Components CC is international standard for information security system evaluation. And, that was approved on June, 1999. Recently, that was revised by 3.1 in v2.3. The fundamental of CC is categorizing universal set of security function requirement doing requisitely in all information security systems hierarchically. Also, is categorizing universal set of assurance requirement hierarchically for accuracy of embodiment about security function. Addition to contents of composed component evaluation by CC v3.1 revision. So, what is composed component? That is combined to this use complete to evaluate product IT substance more than two. Figure 2 is example of composed TOE, that consists of basis component provide service and dependant component that offer service[2]. 3. Definition of evaluation scope 3.1 DefinitionA Data Loss Prevention (DLP) is a computer security term referring to systems that identify, monitor, and protect data in use (e.g. endpoint actions), data in motion (e.g. network actions), and data at rest (e.g. data Copyright c 2014 SERSC 67

Common Criteria Requirement of Data Leakage Protection System storage) through deep content inspection, contextual security analysis of transaction (attributes of originator, data object, medium, timing, recipient/destination and so on) and with a centralized management framework. Systems are designed to detect and prevent unauthorized use and transmission of confidential. Thus the Key Defining Characteristics are Deep Content Analysis, Central Policy management and Broad Content Coverage across multiple platforms and locations [3 and 4]. 3.2 DLP Type Network DLP. Typically a software or hardware solution that is installed at network egress points near the perimeter. It analyzes network traffic to detect sensitive data that is being sent in violation of information security policies. The DLP Network product detects sensitive data while it is being transmitted across the network, and generates events and incidents reflecting policy violations. The targeted data is referred to as Data In Motion. DLP Network can automatically monitor or block identified transmissions, or quarantine messages that may need prior approval before leaving the network. In addition, encryption of emails containing sensitive content can be performed by the operational environment when the TOE is configured to do so. Fig. 1 below shows a typical DLP Network deployment. [Fig. 1] Network DLP End-Point DLP. Such systems run on end-user workstations or servers in the organization. Like network-based systems, endpoint-based can address internal as well as external communications, and can therefore be used to control information flow between groups or types of users (e.g. 'Chinese walls'). They can also control email and Instant Messaging communications before they are stored in the corporate archive, such that a blocked communication (i.e., one that was never sent, and therefore not subject to retention rules) will not be identified in a subsequent legal discovery situation. 68 Copyright c 2014 SERSC

보안공학연구논문지 Journal of Security Engineering Vol.11, No.1 (2014) [Fig. 2] End-Point DL Endpoint systems have the advantage that they can monitor and control access to physical devices (such as mobile devices with data storage capabilities) and in some cases can access information before it has been encrypted. Some endpoint-based systems can also provide application controls to block attempted transmissions of confidential information, and provide immediate feedback to the user. They have the disadvantage that they need to be installed on every workstation in the network, cannot be used on mobile devices (e.g., cell phones and PDAs) or where they cannot be practically installed (for example on a workstation in an internet café). Storage DLP. Typically a software solution that is installed in data centers to discover confidential data is stored in inappropriate and/or unsecured locations (e.g. open file share). 4. Proposed Data Leakage Protection System Protection Profile In this section, we describe the proposed DLP system and protection profile. 4.1 Overview of TOE The most ideal way of data leakage protection is to prevent a leakage from happening in the first place by understanding what needs to be protected, identifying every path or channel that could be used for stealing data, and monitoring them. Since one measure alone cannot block all paths, it seems to be the best way to combine different types of DLPs. This paper suggests an environment where End-Point DLP, Storage DLP, and Network DLP can be operated together and provide a protection profile(pp) to which all these types can conform. The structure of the TOE presented in this PP is as follows: Security Audit: The TOE generates, updates, and reviews the audit records related to the security-relevant events to ensure accountability. It detects potential security violation from audited events and takes actions as necessary. Copyright c 2014 SERSC 69

Common Criteria Requirement of Data Leakage Protection System User Data Protection: The TOE detects possible data leakage and, based on the policy set by an administrator, prevents it and records what happened Identification and Authentication: The TOE identifies and authenticates a user. It takes actions when authentication fails. TOE Access: The TOE provides the functionality to terminate an administrator session after a specified period of administrator inactivity in order to block an unauthorized access to the security management functions. Protection of the TSF: The TOE runs a suite of self-test to verify the integrity of the executable files, configuration data, and TSF executable codes stored in the TOE. It checks the status of connection between its components so that it can preserve a secure state of the TSF. The TOE may perform independently or rely on additional hardware, software, or firmware for operation. This PP can be applied to various types of products. In case an ST author conforms to this PP, he should identify all non-toe hardware, software, or firmware required by the TOE. 4.2 Security Problem Definition This section describes the security aspects of the environment in which the TOE will be used and the manner in which the TOE is expected to be employed. It provides the statement of the TOE security environment, which identifies and explains all: Known and presumed threats countered by either the TOE or by the security environment Organizational security policies with which the TOE must comply Assumptions about the secure usage of the TOE, including physical, personnel and connectivity aspects Threats. This subsection of the security problem definition shows the threats that are to be countered by the TOE. A threat consist of a threat agent, an asset and an adverse action of that threat agent on that asset[2]. The specification of threats should include all threats detected up to now, if it is not done the TOE may provide inadequate protection. In other words, if the specification of threats is insufficiency, the assets maybe exposed to an unacceptable level of risk. In the result, we derive the threats in table 1[4, 5, 6 and 7]. The threat agents are divided into two categories: Attackers who are not TOE users: They have public knowledge of how the TOE operates and are assumed to possess a low skill level, limited resources to alter TOE configuration settings or parameters and no physical access to the TOE. TOE users: They have extensive knowledge of how the TOE operates and are assumed to possess a high 70 Copyright c 2014 SERSC

보안공학연구논문지 Journal of Security Engineering Vol.11, No.1 (2014) skill level, moderate resources to alter TOE configuration settings or parameters and physical access to the TOE. (TOE users are, however, assumed not to be willfully hostile to the TOE.) Both are assumed to have a low level of motivation. The IT assets requiring protection are the user data saved on or transitioning through the TOE and the hosts on the protected network. [Table 1] Threats Name T.Spoofing T.Consecutive Authtication Attempt T.Storaed TSF Data T.TSF Data Transfer T.Recored Failure T.Reuse Attack T.Unauthorized Process T.User Data Leakage T.Failure (End-Poing DLP Only) T.Mnagement Failure T.Analysis Failure T.Unaythorized Action T.Unauth T.Compromise T.Application Execute Description A threat agent can access the TOE by disguising himself as an authorized user. A threat agent can attempt authentication consecutively and obtain the administrator s privilege. An unauthorized user may try accessing the TOE or attack the system in order to change or delete the TOE configuration or get access to the functionality or data of the TOE. The TSF data can be exposed or modified while it is being transferred between different components of the TOE or between the TOE and a remote administrator. A threat agent can cause an action that will exhaust the storage so that the TOE fails to record security-relevant events. A threat agent can reuse the authentication data of an authorized user to access the TOE. A threat agent can start an unauthorized process on a user s PC to steal the user data or stop the TOE. A threat agent can leak the user data without authorization. A threat agent can take advantage of the TOE_Agent when it is not capable of providing services because an attack caused failure. The TOE may fail to take care of a threat agent s inappropriate access to or action taken on the data that needs protection, which may result in the data modified or tampered with. The TOE may fail to detect a threat agent s inappropriate access to or action taken on the data that needs protection, which may result in the data modified or tampered with. A threat agent can access the data that needs to be protected and take unauthorized actions on it. A user can access the TOE and its data even when he is not authorized according to the security policy of the TOE. An unauthorized user can bypass the security mechanism to expose, eliminate, or destroy the integrity of the data collected or generated by the TOE. An attacker can start inappropriate software on the system or make inappropriate changes to the system without being caught. Organizational Security Policy. An Organizational Security Policy (OSP) is a set of security rules, procedures, or guidelines imposed by an organization on the operational environment of the TOE. The organizational security policies for this paper are described in [Table 2]. Copyright c 2014 SERSC 71

Common Criteria Requirement of Data Leakage Protection System [Table 2] Organizational Security Policy Name P.Audit P.Secure Management P.Statistics Description The TOE shall generate and maintain a record of security-related events to ensure accountability. Records shall be reviewed. The TOE shall provide its authorized administrator with a means to manage the TOE securely and keep the TSF data up to date. An authorized administrator shall be able to take statistics on the data of audit and intrusion detection. Assumptions. The assumptions are made on the operational environment in order to be able to provide security functionality. If the TOE is placed in an operational environment that does not meet these assumptions, the TOE may not be able to provide all of its security functionality anymore. Assumptions can be on physical, personnel and connectivity of the operational environment. [Table 3] Assumptions Name A.Dynamic Managment A.Physical Security A.Trusted Admin A.OS Reinforcement A.Access Description The TOE is managed in a way that it can deal with dynamic changes of the assets that need to be protected. The TOE locates in a secure environment that only an authorized administrator can access. (Except for End-point DLP Agent) An authorized administrator of the TOE has no malicious intention, is properly educated in terms of the management functions of the TOE, and follows the administrator s guidance. The TOE has a routine to remove unnecessary services or measures and to fix vulnerability of the OS(e.g. using patches) to ensure credibility and stability of the OS. The TOE can access all IT system data required to enforce its functionality. 4.3 Security Objectives Security objectives are concise, abstract statements of the intended solution to the problem defined by the security problem definition. The set of security objectives for a TOE form a high-level solution to the security problem. This high-level solution is divided into two part-wise solutions: the security objectives for the TOE, and the security objectives for the TOE s operational environment. This section identifies the security objectives for the TOE and its supporting environment. Security Objectives for the TOE. The TOE provides security functionality to solve a certain part of the problem defined by the security problem definition. This part wise solution is called the security objectives for the TOE and consists of a set of objectives that the TOE should achieve in order to solve its part of the problem[2]. 72 Copyright c 2014 SERSC

보안공학연구논문지 Journal of Security Engineering Vol.11, No.1 (2014) [Table 4] Security Objectives for the TOE Name O.Audit O.MNG O.Data Protection O.IA O.Security Access O.Data Collection O.Data Analysis O.Tagging O.Leakage Protection O.Audit Review O.Statistics O.Notice O.Leakage Management O.self Protection Description The TOE shall generate and maintain a record of security-related events to ensure accountability. It shall also provide a means to review the records. The TOE shall provide its authorized administrator with an efficient means to manage the TOE and keep the TSF data up to date. The TOE shall protect the TSF data stored in it from unauthorized exposure, modification, or deletion. The TOE shall uniquely identify a user and authenticate the user before allowing his access to the TOE. Only authorized administrator shall be allowed to access the security functionality, configuration, and data. The TOE shall collect from the managed system the program codes that can be allowed and objects that need to be protected. The TOE shall have an analysis process to decide whether to allow or deny access of an object. The TOE shall be able to identify the data categorized by data analysis. The TOE shall monitor itself to prevent leakage of assets. The TOE shall provide the authorized administrator with functionality to filter, review, and order the audit records. The TOE shall analyze and take statistics on all events according to the policy. The TOE shall raise an alarm according to the policy set for each event. The TOE shall enforce the policy and take actions on the files that hold confidential or secret information; and on the transfer of, user s action on, or access to the information. The TOE shall protect itself from unauthorized access or tampering to its functionality and data in order to maintain the integrity of the system data and audit records. Operational environment of the TOE. The operational environment of the TOE implements technical and procedural measures to assist the TOE in correctly providing its security functionality (which is defined by the security objectives for the TOE). This part wise solution is called the security objectives for the operational environment and consists of a set of statements describing the goals that the operational environment should achieve[2]. [Table 5] Operational environment of the TOE Name OE.Dynamic MNG OE.Physical Security OE.Trusted Admin OE.OS Reinforcement Description The TOE shall be managed in a way that it can deal with dynamic changes of the system that needs to be protected. The TOE shall be located in a secure environment that only an authorized administrator can access. An authorized administrator of the TOE shall have no malicious intention, be properly educated in terms of the management functions of the TOE, and follow the administrator s guidance. The TOE shall have a routine to remove unnecessary services or measures and to fix Copyright c 2014 SERSC 73

Common Criteria Requirement of Data Leakage Protection System OE.Timestamp OE.Access OE.Timestamp vulnerability of the OS(e.g. using patches) to ensure credibility and stability of the OS. The TOE shall record security-relevant events accurately using the reliable timestamp provided in the operational environment. The TOE shall be able to access all IT system data required to enforce its functionality. The IT environment shall provide the TOE with a reliable timestamp. 4.4 Extended Components Definition (ASE_ECD) This section specifies the extended SFRs for the TOE. The extended SFRs are organized by class. [Table 6] identifies all extended SFRs implemented by the TOE and a detailed description of each component is in [Table 7]. [Table 6] Extended TOE Security Functional Requirements Class Name Component Name Description Security Management EXT_FMT_STA.1 Data statistics of audit and leakage detection EXT_FDP_COL.1 Monitored data collection User Data Protection EXT_FDP_ANL.1 Monitored data analysis EXT_FDP_MON.1 Real-time monitoring of data leakage EXT_ FDP_PRV.1 Prevention of data leakage [Table 7] Datailed Description of Extended TOE SFR 74 Family Behavior Component description & structure Family Behavior Component description & structure EXT_FMT_STA.1 Data statistics of audit and leakage detection (FMT_STA, Statistics) This family provides the functionality to take statistics on the data generated as a result of audit and detection of leakage. EXT_FMT_STA.1 Data statistics of audit and leakage detection provides an authorized administrator with the capability to take statistics on the data. EXT_FMT_STA.1 Data statistics of audit and leakage detection Hierarchical to: No other components Dependencies: FAU_GEN.1 Audit data generation EXT_FDP_ANL.1 Monitored data analysis EXT_FDP_REV.1 Prevention of data leakage EXT_FMT_STA.1.1 The TSF shall provide [assignment: an authorized user] with the capability to take statistics on the data generated as a result of audit and detection of leakage. EXT_FDP_COL.1 Monitored data collection (EXT_FDP_COL, Collection) This family intends to collect the data for monitoring from the user data in the protected system. EXT_FDP_COL.1 Monitored data collection collects the data for monitoring from the protected system to prevent data leakage. EXT_FDP_COL.1 Monitored data collection Hierarchical to: No other components Dependencies: No dependencies Copyright c 2014 SERSC

보안공학연구논문지 Journal of Security Engineering Vol.11, No.1 (2014) Family Behavior Component description & structure Family Behavior Component description & structure Family Behavior Component description & structure EXT_FDP_COL.1.1 The TSF shall collect [assignment: list of data that needs to be collected] from the protected system according to [assignment: criteria of data collection] to prevent data leakage. EXT_FDP_COL.1.2 The data collected by the TSF shall include the following information: Date and time of the event [Assignment: additional attributes of the data for monitoring] EXT_FDP_ANL.1 Monitored data analysis (EXT_FDP_ANL, Analysis) This family intends to analyze and identify the data collected for monitoring. EXT_FDP_ANL.1 Monitored data analysis analyzes and identifies the collected data to prevent data leakage. EXT_FDP_ANL.1 Monitored data analysis Hierarchical to: No other components Dependencies: EXT_FDP_COL.1 Monitored data collection EXT_FDP_ANL.1.1 The TSF enforces the following analysis functionality based on the collected data. a) [Assignment: function to analyze the data] EXT_FDP_ANL.1.2 The TSF shall identify the data categorized by the analysis functionality. EXT_FDP_MON.1 Real-time monitoring of data leakage (EXT_FDP_MON, monitoring) This family intends to monitor if the identified data is being leaked in real time. EXT_FDP_MON.1 Real-time monitoring of data leakage monitors the data and possible way of leakage in real time to prevent data leakage. EXT_FDP_MON.1 Real-time monitoring of data leakage Hierarchical to: No other components Dependencies: No dependencies EXT_FDP_ANL.1.1 The TSF shall ensure that the function to enforce the policy is invoked and performed successfully before the data is leaked. EXT_FDP.PRV.1 Prevention of data leakage (EXT_FDP_PRV, Prevention) This family intends to detect and prevent data leakage. EXT_FDP_PRV.1 Prevention of data leakage prevents data leakage from the protected system according to the policy set by an authorized administrator. EXT_FDP_PRV.1 Prevention of data leakage Hierarchical to: No other components Dependencies: EXT_FDP_MON.1 Real-time monitoring of data leakage EXT_FDP_PRV.1.1 The TSF shall perform the following in case potential security violation or data leakage is detected. a) Notify the authorized administrator b) Take actions as directed by the management of security functions c) Collect detailed information regarding the events of security violation d) [Assignment: Take actions in case of security violation in the protected system] EXT_FDP_PRV.1.2 The TSF shall store the following information about the actions taken. a) Actions taken and the result [Assignment: Information regarding the security violation in the protected system] 4.5 Security Functional Requirements The Security functional requirements substantiate the security objectives. Each security functional requirement must be related to one or more security objectives. These requirements are defined in CC part 2, and protection profile author just chooses and uses appropriate requirements. In addition, if the requirements defined Copyright c 2014 SERSC 75

Common Criteria Requirement of Data Leakage Protection System in CC part 2 are not sufficient to demonstrate the security objectives, then, the protection profile author can refine and reinforce conditions in detail to established requirements. The security functional requirements for this paper are described in [Table 8]. [Table 8] The Security Functional Requireiments Security Functional Class Components FAU_ARP.1 Security alarms FAU_GEN.1 Audit data generation FAU_GEN.2 User identity association FAU_SAA.1 Potential violation analysis Security audit FAU_SAR.1 Audit review FAU_SAR.3 Selectable audit review FAU_SEL.1 Selective audit FAU_STG.1 Protected audit trail storage FAU_STG.3 Action in case of possible audit data loss FAU_STG.4 Prevention of audit data loss FDP_ACC.1 Subset access control FDP_ACF.1 Security attribute based access control FDP_IFC.1 Subset information flow control User Data Protection FDP_IFF.1 Simple security attributes EXT_FDP_COL.1 Monitored data collection EXT_FDP_ANL.1 Monitored data analysis EXT_FDP_MON.1 Real-time monitoring of data leakage EXT_FDP_PRV.1 Prevention of data leakage FIA_AFL.1 Authentication failure handling FIA_ATD.1 User attribute definition Identification and FIA_SOS.1 Verification of secrets authentication FIA_UAU.2 User authentication before any action FIA_UAU.7 Protected authentication feedback FIA_UID.2 User identification before any action FMT_MOF.1 Management of security functions behavior FMT_MSA.1 Management of security attributes Security Management FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles EXT_FMT_STA.1 Data statistics of audit and leakage detection Protection of the TSF FPT_STM.1 Reliable time stamps FPT_TST.1 TSF testing TOE Access FTA_SSL.3 TSF-initiated termination Our protection profile adopts EAL 4+ level in common criteria. Because DLP System is a critical information system and the result of attack can cause terrible confusion in society, we extend security assurance requirements to reinforce verification of implementation DLP system. Extended requirements are ADV_IMP.2, ATE_DPT.3, AVA_VAN.4. 76 Copyright c 2014 SERSC

보안공학연구논문지 Journal of Security Engineering Vol.11, No.1 (2014) 5. Conclusion Many companies are adopting a DLP system hoping that it can solve the desperate problem they are facing, risk of data leakage. This paper intends to suggest a baseline for introducing/evaluating a DLP system and eventually help protect data and prevent its theft or leakage. However, unlike the perimeter security, which is the essential aspect of IT security, data leakage protection is more about business than IT technologies because it deals with information assets, which is the most important thing to a company. That is, mere introduction of a DLP system does not prevent data leakage. For a complete prevention of data leakage, not only the IT team members but all company workers should aware their roles and responsibilities References [1] Seung-youn Lee and Myong-chul Shin, Protection Profile for Software Development Site, LNCS(2005) Vol. 3481, pp. 499-507. [2] ISO/IEC 15408, Common Criteria for Information Technology Security Evaluation Part 1, 2, 3, Version 3.1 R4, Cocmmon Criteria, September(2012). [3] Prathaben Kanagasinghan, Data Loss Prevention, SANS Institute InfoSec Reading Room, August(2008). [4] SANS Institute, Understanding and Selecting a Data Loss Prevention Solution, December(2007). [5] McAfee, Application Control v5.0, Change Control v5.0, and Integrity Monitor v5.0 with McAfee Agent v4.5 and epolicy Orchestrator v4.5, December 14(2010). [6] RSA, Data Loss Prevention Suite v6.5 Security Target Document Version 0.7, April(2009). [7] Aberdeen Group, The Cost-Based Business Case for DLP, June(2009). Copyright c 2014 SERSC 77

Common Criteria Requirement of Data Leakage Protection System Authors Hyun-Jung Lee 2001. 2 Sungshin. Univ 2011. 2 Sungkyunkwan. Uinv MA/PhD ABD 2007. 8 Korea Internet & Security Agency, Researcher 2008. 8 Financial Security Agency, Researcher 2008. 9 Current Korea System Assurance, lnc. TA Team, Manager Research Interests : Cloud Security, Information Security, Security Evaluation Seung-Eun Jeong 2013.2 Sungshin Women s Univ.(B.Eng) 2013.1~ Current Korea System Assurance, lnc. TA Team, Evaluator Research Interests: Software Engineering, Security Evaluation. Jae-In Shin 2009.2 Hannam. Univ 2011.8 Hannam. Univ.(MS) 2013.1~ ICurrent Korea System Assurance, lnc. R&D Team, Researcher Research Interests: Software Engineering, Security Engineering, Security Evaluation, Risk Analysis, Wireless Security, Smart Phone Security Kab-Seung Kou 2005.2 Youngdong. Univ.(BS) 2007.2 Hannam. Univ.(MS) 2011.2 Hannam. Univ.(Ph.D) 2012.7 Infosec Technology Co. NRnD Team, Research Engineer 2012.8~ Current Korea System Assurance, lnc. R&D Team, Manager Research Interests: Software Engineering, Security Engineering, Security Evaluation, Risk Analysis, Wireless Security, Smart Phone Security 78 Copyright c 2014 SERSC