• No se han encontrado resultados

Design and development of a translation and enforcement module for cybersecurity policies

N/A
N/A
Protected

Academic year: 2020

Share "Design and development of a translation and enforcement module for cybersecurity policies"

Copied!
78
0
0

Texto completo

(1)UNIVERSIDAD POLITÉCNICA DE MADRID ESCUELA TÉCNICA SUPERIOR DE INGENIEROS DE TELECOMUNICACIÓN. GRADO EN INGENIERÍA DE TECNOLOGÍAS Y SERVICIOS DE TELECOMUNICACIÓN. TRABAJO FIN DE GRADO. DESIGN AND DEVELOPMENT OF A TRANSLATION AND ENFORCEMENT MODULE FOR CYBERSECURITY POLICIES FERNANDO MONJE REAL Madrid, España 2018.

(2)

(3) DESIGN AND DEVELOPMENT OF A TRANSLATION AND ENFORCEMENT MODULE FOR CYBERSECURITY POLICIES Autor: Fernando Monje Real Tutora: Irene Romero Ibáñez Departamento de Ingeniería de Sistemas Telemáticos ESCUELA TÉCNICA SUPERIOR DE INGENIEROS DE TELECOMUNICACIÓN. GRADO EN INGENIERÍA DE TECNOLOGÍAS Y SERVICIOS DE TELECOMUNICACIÓN. TRABAJO FIN DE GRADO. 2018.

(4)

(5) Presidente:. Vocal:. Secretario:. Suplente:. Realizado el acto de defensa y lectura del TFM el día Madrid, habiendo obtenido la calificación de. El presidente,. El secretario,. de. de. El vocal,. en.

(6)

(7) Abstract. Nowadays, cyber attacks constitute a bigger threat to organizations than before, given the higher sophistication of those attacks, their growing propagation velocity and the increase of their destructive capabilities. This problem requires solutions capable of answering in real time and automatically. This Bachelor Thesis proposes a possible solution: the development of a system capable of translating a high level security policy designed by an organization into another low level policy, so that it can be interpreted by the elements of the network in charge of the security. This conversion process is performed after the calculation of a risk level of the organization, according to which the aforementioned translation will be executed. This risk calculation will be carried out using the data obtained by an IDS monitoring the organization’s network. Once the kind of threat is detected, a certain risk level is inferred. Afterwards, the high level policy corresponding to that risk level will be translated into an intermediate level. This intermediate policy takes into account the topology of the network but it is still impossible to understand by the elements in charge of the network security, such as the firewalls. Finally, the translation will be carried out at a low level using an independent module. In this case, the chosen firewall is Iptables, and the set of rules created must be in the proper format. These rules are now understandable by firewalls and therefore, can be automatically deployed in the network.. Keywords: Cyber Attack, Risk, Cyber Security, Iptables, Firewall, Automatic Response System, Security Policies..

(8)

(9) Resumen. En la actualidad, los ciberataques constituyen cada vez una mayor amenaza a las organizaciones, dada la mayor complejidad de dichos ataques, su creciente velocidad de propagación y el aumento de su capacidad destructiva. Esta problemática exige soluciones capaces de responder en tiempo real y de manera automática. Una posible solución, presentada en este Trabajo de Fin de Grado consiste en el desarrollo de un sistema capaz de traducir una política de seguridad de alto nivel diseñada por una organización a otra política de bajo nivel, de forma que pueda ser interpretada por los elementos de red encargados de la seguridad. Este proceso de traducción se realiza tras el cálculo de un nivel de riesgo de dicha organización y, de esta forma, las políticas traducidas son adecuadas para el contexto de la organización. Éste cálculo del riesgo se realizará a partir de los datos obtenidos por un IDS situado en cualquier punto de la red de la organización. Una vez se detecte el tipo de amenanza, se calculará un nivel de riesgo adecuado. A continuación, se traducirá la política de alto nivel definida para dicho nivel de riesgo, a un nivel intermedio. Esta política de nivel intermedio tendrá en cuenta la topología de red pero todavía incomprensible para los elementos encargados de implementar la seguridad como, por ejemplo, los firewalls. Por último, se realizará la traducción a un nivel bajo mediante un módulo independiente, en este caso, será a un formato Iptables, creando un conjunto de reglas. Dichas reglas, ya podrán ser interpretadas por los firewalls y por lo tanto, se podrán desplegar automáticamente en los elementos de la red.. Palabras clave: Ciberataque, Riesgo, Ciberseguridad, Iptables, Cortafuegos, Sistema de Respuesta Automático, Políticas de Seguridad..

(10)

(11) Index. . Abstract . Resumen . List of Figures . List of Tables . Acronyms. 1. Introduction 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1 1. 2. State of the Art. 3. 3. Development. 7. 3.1. High Level to Low Level Translation Functionality . . . . . . . . . . . .. 7. 3.1.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7. 3.1.2. GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 11. 3.1.3. Work Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 15. 3.2. Automatic Intrusion Response Functionality . . . . . . . . . . . . . . . .. 21. 3.2.1. Configuration Module . . . . . . . . . . . . . . . . . . . . . . .. 21.

(12) 3.2.2. Automatic Rules Uploader Module . . . . . . . . . . . . . . . .. 24. 3.2.3. IDS Configuration . . . . . . . . . . . . . . . . . . . . . . . . .. 24. 3.2.4. Socket Module . . . . . . . . . . . . . . . . . . . . . . . . . . .. 25. 4. Validation. 27. 4.1. Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 28. 4.1.1. Test case 1: Proof of Concept . . . . . . . . . . . . . . . . . . .. 29. 4.2. Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 33. 4.2.1. Test case 1: Big roles . . . . . . . . . . . . . . . . . . . . . . . .. 34. 4.2.2. Test case 2: Path discovery . . . . . . . . . . . . . . . . . . . . .. 36. 4.2.3. Test case 3: Quarantine . . . . . . . . . . . . . . . . . . . . . . .. 38. 4.2.4. Test case 4: Dishonest Employee . . . . . . . . . . . . . . . . . .. 41. 5. Conclusions. 45. 5.1. Achieved Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 46. 5.2. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 48. Appendixes. 51. I. Impact of this Project. 51. A.. Social Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 51. B.. Economic Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 51. C.. Environmental Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 52. D.. Ethical and Professional Implications . . . . . . . . . . . . . . . . . . .. 52. II. Cost of the System. 53. A.. Physical Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 53. B.. Human Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 54.

(13) C.. General Expenses and Industrial Profit . . . . . . . . . . . . . . . . . . .. 55. D.. Expendable material . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 55. E.. Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 55. F.. Subtotal Budget before VAT . . . . . . . . . . . . . . . . . . . . . . . .. 55. G.. General Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 56. Bibliography. 58.

(14)

(15) Figures. 1.. Most used security policies languages [1] . . . . . . . . . . . . . . . . .. 5. 2.. Main screen of the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . .. 11. 3.. Role screen of the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . .. 12. 4.. Expanded role screen of the GUI . . . . . . . . . . . . . . . . . . . . . .. 13. 5.. Role creation screen of the GUI . . . . . . . . . . . . . . . . . . . . . .. 14. 6.. Role creation with added excluded roles fields . . . . . . . . . . . . . . .. 14. 7.. Configuration module asking for password information . . . . . . . . . .. 22. 8.. Configuration module sending SSH keys to firewalls . . . . . . . . . . .. 23. 9.. Configuration module asking for individual passwords . . . . . . . . . .. 23. 10.. Configuration module setting up all the firewalls . . . . . . . . . . . . . .. 23. 11.. First scenario network topology . . . . . . . . . . . . . . . . . . . . . .. 28. 12.. Permissions of the Proof of Concept test case . . . . . . . . . . . . . . .. 29. 13.. Roles of the Proof of Concept test case . . . . . . . . . . . . . . . . . . .. 30.

(16) 14.. Activities of the Proof of Concept test case . . . . . . . . . . . . . . . . .. 30. 15.. Views of the Proof of Concept test case . . . . . . . . . . . . . . . . . .. 31. 16.. Second scenario network topology . . . . . . . . . . . . . . . . . . . . .. 33. 17.. Roles of Big roles test case . . . . . . . . . . . . . . . . . . . . . . . . .. 34. 18.. The activity of Big roles test case . . . . . . . . . . . . . . . . . . . . . .. 35. 19.. Views of Big roles test case . . . . . . . . . . . . . . . . . . . . . . . . .. 35. 20.. Permissions of Big roles test case . . . . . . . . . . . . . . . . . . . . . .. 35. 21.. Roles of Path discovery test case . . . . . . . . . . . . . . . . . . . . . .. 37. 22.. Activity of Path discovery test case . . . . . . . . . . . . . . . . . . . . .. 37. 23.. View of Path discovery test case . . . . . . . . . . . . . . . . . . . . . .. 37. 24.. Permission of Path discovery test case . . . . . . . . . . . . . . . . . . .. 38. 25.. Permissions of Quarantine test case . . . . . . . . . . . . . . . . . . . .. 39. 26.. Firewall 2 Iptables rules before the infection in Quarantine test case . . .. 40. 27.. Firewall 2 Iptables rules after the infection in Quarantine test case . . . .. 41. 28.. Permissions of Dishonest employee test case . . . . . . . . . . . . . . . .. 42. 29.. Firewall 3 Iptables rules before the internal attack in Dishonest Employee test case . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 43. Firewall 3 Iptables rules after the internal attack in Dishonest Employee test case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 44. 30..

(17) Tables. 1.. Cost of material resources (direct cost) . . . . . . . . . . . . . . . . . . .. 54. 2.. Labor cost (direct cost) . . . . . . . . . . . . . . . . . . . . . . . . . . .. 54. 3.. General costs and industrial benefit . . . . . . . . . . . . . . . . . . . . .. 55. 4.. Subtotal of the budget plus VAT applied . . . . . . . . . . . . . . . . . .. 55. 5.. Final budget of the project . . . . . . . . . . . . . . . . . . . . . . . . .. 56.

(18)

(19) Acronyms. GUI Graphical User Interface AIRS Automatic Intrusion Response System IDS Intrusion Detection System SSH Secure Shell OS Operative System XML Extensible Markup Language XACML eXtensible Access Control Markup Language RBAC Role-based access control FW Firewall TCP Transmission Control Protocol UDP User Datagram Protocol ICMP Internet Control Message Protocol MZ Militarized Zone DMZ Demilitarized Zone JVM Java Virtual Machine VNX Virtual Networks over LinuX FTP File Transfer Protocol PC Personal Computer.

(20)

(21) 1 Introduction. 1.1.. Objectives. The main objectives of this project are making the process of designing, maintaining and enforcing the cybersecurity policy of an organization easier and allowing organizations to automatically respond to cyberthreats in real time. To make these goals a reality, the approach taken in this project aims to let the security administrator write the policies in a high-level language, independent from the network‘s topology and from the technology used by the security enforcement elements. In order to accomplish the main goals, some smaller goals have to be achieved: 1. The first goal is to design a high-level policy definition system. It must allow the administrator to write the allowed traffic flows in an easy, interactive and modular way. It also has to help the administrator find misconfigurations in the policies. 2. The second goal is to design a system able to understand the high-level policies and transform them to a language understandable by the security enforcement elements. The approach is going to be a translation to an intermediate level of abstraction which will still be independent from the language the security elements use but that will take into account the network‘s topology. This approach allows to define any parser, that converts this abstract level to a concrete level the security elements understand. 3. The third goal is to upload the translated policies from where they are generated.

(22) INTRODUCTION to the concerned security elements automatically. It has to be done without human interaction and in a secure way. 4. The forth and last goal is to design a communication and decision system which will allow a IDS to communicate with the computer translating the policies, and then to infer the risk level of the organization and apply the adequate security policy, ultimately allowing the organization to be protected of cyber attacks in real time.. 2.

(23) 2 State of the Art. In recent years cyber threats have become more sophisticated and therefore efforts have been oriented to enhancing the security of the systems. Nowadays, there are great improvements in detecting those threats but not so much at reacting to them. The main problem is that human interaction is slow and thus the counter measures should be inferred and deployed automatically in order to be effective against cyber attacks. To overcome this problematic, AIRSs (Automatic Intrusion Response Systems) were invented. This kind of systems rely on IDS (Intrusion Detection System) which are in charge of detecting the intrusion and notifying it to the AIRS. In order to work, AIRS need certain metrics for deciding the optimal response in each scenario depending on the context and other parameters. These metrics are as diverse as the importance of the network element being compromised, the cost of the possible response, the IDS confidence and several more. In recent years, various AIRSs have being proposed. Some of the most important are the ones mentioned in [2]. All of them take different metrics into account when inferring the response: Stakhanova’s IRS [3] : This system is mostly based in two different metrics. • Damage reduction metric: It compares the damage the intrusion could cause and the damage the response could have and therefore chooses the least harmful response which mitigates the attack. • Maximum benefit at the lower risk metric: This metric also considers the.

(24) STATE OF THE ART negative impact that the response could have and it also ponders the success of the responses already taken in the past. AAIRS [4] : It considers three metrics: • IDS confidence metric: This AIRS measure the rate of false positives the IDS has. • Attack identification metric: The system detects the type of the intrusion and reacts accordingly. • Response success metric: Also considers past responses and their achievement level. IDAM&IRS [5] : It is one of the newest AIRS. It has a set of responses associated with a certain risk level. Whenever an intrusion is detected, a risk level is calculated, and therefore if this risk is greater than the one associated with a possible response, the response is deployed. It is a similar approach to the one proposed in this work. the alert is triggered, the response has to be inferred using a security policy and the various metrics previously mentioned. In today’s networks, there are various types of elements from several vendors with different OSs, such as Linux based distributions, or Windows, and each OS allowing different configurations. The design of a security policy that takes into account all the previously mentioned possibilities is very problematic. That is why there has been an effort in making the security policies independent from the component in charge of enforcing it. In other words, the objective has been the design of systems able to understand high level security policies and then to translate them to a language that the components in charge of enforcing the policies are able to comprehend. That is the approach taken in [6] where authors present a Or-BAC model (Organization Based Access Model). The policies are written using this model, then translated into an intermediate level of abstraction, still agnostic from the component where the rules are going to be deployed, which is the same approach taken in [7], where this abstract level is closer to the real organization network‘s topology. There are more ways to specify a Security Policy, and their benefits and limitations are discussed in [1] where they present the most used policy languages are presented. In Fig.1 are the main ones with their most remarkable features. 4.

(25) Figure 1 : Most used security policies languages [1]. Some of the most distinguished are:. Ponder: It is an object-oriented and declarative policy language [8]. It uses the RBAC model (Role-Based Access Control). The interaction between roles are defined as relationships. It’s not XML based but it can be translated into an XML representation if needed. The element in charge of enforcing the policies it’s called PEP (Policies Enforcement Point) and is written in Java [9]. EPAL: It is XML-based language and was proposed by IBM [10]. It is focused on privacy policies and unlike other policy languages it’s not very easy to implement correctly. It uses a purpose-based access control, where the authorization decision is evaluated by the subject’s purpose of using the requested service. This access control mechanism is easier than RBAC but requires a well-structured purpose element. IBM has considered this problem and thus palliated this limitation by providing tools to facilitate the implementation of this policy language [11] VALID: (Virtualization Assurance Language for Isolation and Deployment) It is a language to express high-level security goals specially useful in virtualized infrastructures hosted in the cloud. It is based on IF (Intermediate Format) [12] which helps building a formal foundation to facilitate automated reasoning. It can be used to write access control rules, so it is able to deploy them automatically and finally validate them. XACML: (eXtensible Access Control Markup Language) It is the most used one. XACML is a declarative language, based in XML. One of the main features it provides is the policy combination procedure, used when more than one policy is applied, using several algorithms [13] to avoid conflict. It also has the possibility 5.

(26) STATE OF THE ART of adding more combining algorithms. There is a tool called Sun’s XACML Open Source Implementation [14] which is commonly used for the implementation and enforcement of policies written in XACML. It only provides limited support for the RBAC model but a more in-depth integration has been done in xfACL (eXtensible Functional Language for Access Control) [15].. 6.

(27) 3 Development. In this section the two main features of the system are going to be explained, being the first one the translation functionality, and the second one the automatic intrusion response functionality.. 3.1.. High Level to Low Level Translation Functionality. This functionality aims to allow a network‘s administrator to write a security policy reducing the complexity of the process by making it independent of the network‘s security enforcement elements, such as firewalls.. 3.1.1.. Inputs. The module requires the following four files written in XML format as inputs:. Roles It is the document where the roles are written. A role represents a network element or a set of them and it consists of: name: It is the name of the role and it can be any set of alphanumeric characters with three exceptions. If is a firewall, it must follow this pattern: FW_«name of the.

(28) DEVELOPMENT firewall»_«interface». It is required that the different interfaces of the same firewall share the same «name of the firewall». Another exception is that the role considered Internet has to be called «Internet». The last one is that the name of the administrator role has to be «Admin». addr and mask: This fields are the IP address and the network mask of the role. There can be any combination between them. If the role is Internet, its field «addr» has to be «internet» and his mask can be any number because it is irrelevant. There is an optional field called «hostExclusion», which is made of one or more roles. This field can be used if you want to exclude a certain role whose address and mask are contained in the ones defined in your role. For example, you may want your entire organization to access the Internet except the administrator, so in that case you would create a role with the addr and mask of the organization’s network but exclude the administrator’s PC. In that case you would add the administrator’s PC role to the exclusion roles of this new role. Here is an example of a role in the XML file: <relevantRole name="Interna"> <roleDefinition> <hostlnclusion> <subNet> <addr>10.1.3.0</addr> <mask>24</mask> </subNet> </hostlnclusion> <hostExclusion> <role roleName="FW_2_i"/> <role roleName="FW_3_e"/> <role roleName="FW_4_e"/> <role roleName="Admin"/> </hostExclusion> </roleDefinition> </relevantRole>. In this case the address and mask in the subnet field contains the IPs of certain interfaces of some firewalls. As that is no desired in this case, they are written in the hostExclusion field.. 8.

(29) 3.1. HIGH LEVEL TO LOW LEVEL TRANSLATION FUNCTIONALITY Activities The activities are the group of possible actions that can be made in your organization. They have three fields: relevantActivity: In the attribute «name» of this tag is where the name of the activity has to be written, it can be any combination of alphanumeric characters. protocol: In the attribute «type» of this tag is where the protocol of the activity is defined. It can be «tcp», «udp», or «icmp». destPort: This field is needed in the case that the protocol is «tcp» or «udp». It can have one or more singlePort fields inside. Each singlePort field is made of the number of the port you want to allow. Here is an example of an activity in the XML file: <relevantActivity name="Web_HTTP"> <activityDefinition> <protocol type="tcp"> <destPort> <singlePort>80</singlePort> <singlePort>8080</singlePort> </destPort> </protocol> </activityDefinition> </relevantActivity>. This is the definition of an activity called «Web_HTTP» which defines the use of port 80 and 8080 using the TCP protocol.. Views The views are the possible roles to which access can be granted. Each one has two fields: relevantView: In the attribute «name» has to be specified the name of the view, it doesn’t have any restrictions. toTarget: In the attribute «roleName» is where the name of the role that can be reachable has to be written. 9.

(30) DEVELOPMENT An example of a view is the XML file is: <relevantView name="To_DMZ"> <viewDefinition> <toTarget roleName="DMZ"/> </viewDefinition> </relevantView>. Being the DMZ the role for Demilitarized Zone in the organization. This view allows the role «DMZ» to be used as a destination role.. Permissions This is the file where the security policy is written. The permissions are classified in risk levels from 0 to 10, being 0 the lowest risk and 10 the highest. This file has two main sections:. Info: This section is made of three XML tags: • companyNetwork: In this tag the organization’s IP and mask has to be written in CIDR notation, which has this format «xxx.xxx.xxx.xxx/yy» being the «x» the numbers corresponding to the Internet address and «y» to the mask. • initialCompanyRiskLevel: The input is a number from 0 to 10. It specifies the risk level the organization starts at when the module is executed for the first time. • automaticRulesUpload: This tag accepts two options: «yes» or «no». If the «yes» option is selected the rules will be uploaded automatically to the firewalls, nonetheless if the choice is «no», the rules will only be written in plain text format into a file allocated in the same folder the program executable is at. Here is an example of and Info section containing the three tags: <automaticRulesUpload>yes</automaticRulesUpload> <initialCompanyRiskLevel>0</initialCompanyRiskLevel> <companyNetwork>10.1.0.0/21</companyNetwork>. 10.

(31) 3.1. HIGH LEVEL TO LOW LEVEL TRANSLATION FUNCTIONALITY Risks: Here is where the permissions are written. They are classified in ten risk levels, each risk level holding one or more permissions. A permission has the following attributes: • roleName: Is the name of the role from where the resource wants to be accessed. • activityName: Is the activity‘s name that wants to be performed over the view by the role. • viewName: Is the name of the view that the role wants to reach. Here is an example of the risk level 0 with two permissions inside: <Risk level="0"> <permission roleName="DMZ" activityName="PING" viewName=" To_Internet"/> <permission roleName="Web_server" activityName="STREAMING" viewName="To_Internet"/> </Risk>. If the risk of the organization is 0 then this set of rules would be translated. The first permission for example, allows the «DMZ» role to use the activity «PING» over the view «To_Internet». In other words, this permission allows the network elements inside the DMZ to do pings via the ICMP protocol to any machine outside the organization.. 3.1.2.. GUI. Since the goal was to facilitate writing a security policy as much as possible, a GUI (Graphical User Interface) has been created to read the XML documents easily and to edit them. It has been written in Java using it is Swing library. The first screen is shown in Fig.2. Figure 2 : Main screen of the GUI 11.

(32) DEVELOPMENT When a button is clicked another screen will show up with the information about the selected XML. For example, clicking in «Open Roles» will show this information about the Roles file Fig.3. Figure 3 : Role screen of the GUI. Each node can be opened by clicking on it to show more information. If the button 12.

(33) 3.1. HIGH LEVEL TO LOW LEVEL TRANSLATION FUNCTIONALITY «Expand all» is pushed, all the roles will expand Fig.4. Figure 4 : Expanded role screen of the GUI. As is seen in Fig.4 each role has an IP and a Mask, it is also possible to have excluded roles with the name of them inside. The «Compress all» button would do the opposite. 13.

(34) DEVELOPMENT By clicking on the «Create new role» this window will appear Fig.5. Figure 5 : Role creation screen of the GUI. Here the administrator will have to fill each field, if he wants to add an exclusion role, he can do it by clicking on the «Add exclusion role» button as many times as exclusion roles he wants to add, for example if two roles wanted to be added it would look like in Fig.6. Figure 6 : Role creation with added excluded roles fields. Finally, by pushing «Save» and if all the fields are correctly written a success message will appear, saving the information to the XML and refreshing the information shown in Fig.3. 14.

(35) 3.1. HIGH LEVEL TO LOW LEVEL TRANSLATION FUNCTIONALITY 3.1.3.. Work Flow. Once all the files are set, the program can be executed. As the GUI, it is also written in Java because Java programs run in the JVM (Java Virtual Machine). Therefore it will work under different Operative Systems, like Windows, or Linux distributions. The first thing the program does is to generate an XML file called FirewallRelevantRoles. In this file the roles relevant to the various firewalls are written. A role is relevant to a firewall when the firewall can reach it with any of its network interfaces in one hop. In order to do this task, the Roles file is read using the DOM XML Parser. The firewalls are identified from the rest of the roles because they have to start with «FW», as explained before, thus reading also its interfaces distinguished because they are written like «FW_NameOfTheFirewall_Interface1», lastly storing all the IPs of the firewall interfaces. Then, the next step is to find out if a firewall can reach a role in one hop. It can be done by checking if the subnet the role is into is accessible directly from any interfaces of the firewall. To do this, it is required to know if an IP with a mask contains another IP with a different mask. An algorithm has been created which is able to tell if the mask and the IP does not match, for example: 10.1.0.128/24 would not be right, it should be 10.1.0.0/24 and if two subnets have IPs in common. This algorithm is executed for each role, to find out if a role‘s subnet contains a firewall interface, in which case, that role would be relevant to the firewall. By doing this process the file can be written and example of it would be: <Firewall name="FW_2"> <RelevantRoles> <role>DMZ</role> <role>FW_2_internal</role> <role>FW_2_external</role> <role>Web_server</role> <role>DNS_server</role> <role>Admin</role> </RelevantRoles> </Firewall>. As can be seen all the roles reachable from the «FW_2» in one hop are written down, even the interfaces of the analyzed firewall. This information will be crucial to discover the firewalls of the organization affected by a permission. The next task the program does is read from the Info section of the Permission’s file the organization initial risk, in order to know what set of permissions have to be 15.

(36) DEVELOPMENT translated. Once the set of permissions is chosen, the program reads the first one, and loads its information: It reads the role field, looks for the role in the Roles file and stores its IP, mask and excluded roles if there are any. Then it reads the activityName, looks for it in the Activities file and saves its protocol and ports if needed. Finally reads the viewName, then looks for it in the Views file, takes its associated role, then consults the Roles file and saves its IP and mask. Now, the program has all the information about the permission, which is, the IP and mask from the role who wants to access the resource (from now on subjectRole) and the names of the roles excluded, the type of access the permission alows, in other words, its protocol and ports if needed, and lastly the IP and mask of the role trying to be accessed (from now on viewRole). Then before anything it checks that the IP and mask of the subjectRole does not contain any IPs inside the subnet of the viewRole, and also alerts if a role’s IP is not coherent with its mask. If they have IPs in common it means that they can reach each other in one jump, so they would not need to go across a firewall, thus the program finishes with a warning. Nevertheless, if the algorithm does not detect any IPs in common, that means they are at least in different subnetworks and there could be at least one firewall between them. Now it is time to find out what firewalls are affected by a permission, in order to know in which one‘s rules will have to be written to allow the network traffic. This process is done by another algorithm asking the possible firewalls their IP routes via SSH by the procedure described below: It starts by looking in the previously generated FirewallRelevantRoles file and registers the firewalls relevant to the subjectRole and the ones relevant to the viewRole. So, it has two lists of firewall names, one being the firewalls concerning the subjectRole and the other, the firewalls concerning the viewRole. So, for example, it knows that for each list, the subjectRole’s one, has a firewall to which the traffic is going to flow through. Then, making the assumption that the traffic flow uses the same network path in both directions, starts to work with the smaller list, and so the one that haves less possible. 16.

(37) 3.1. HIGH LEVEL TO LOW LEVEL TRANSLATION FUNCTIONALITY firewalls to check and therefore optimizing the program. At this point in time the program enters a recurrent method: The firewalls relevant to the permissions are going to be inferred using its routing tables, in order to be coherent with the design of the network. The first time, it asks a random firewall written in the concerned firewalls list of the role, via SSH using this command: ssh root@"firewall address" ip route get "destination subnet". Being «firewall address» the IP of the selected one, and the destination subnet is the viewRole, or the subjectRole depending of the selected list, for example, if the selected one was the one containing the firewalls relevant to the subjectRole the “destination subnet” parameter is going to be the viewRole address and vice versa. Then, it analyzes the response. If the petition of the destination address is not reachable in one hop by the asked firewall the response is going to look like this: "destination address" via "next hop address" dev eth0 .... Being the important information the field «next hop address», which is the next routing element used to reach the «destination address». The other possibility is having the destination at one hop, in this case the response would look like this: "destination address" dev eth0 .... Meaning that there are no more network routing elements involved in this traffic. Using all this information and considering all the possibilities the affected firewalls by the permission are calculated. Finally, knowing the source address, the destination address, the type of traffic, the ports is going to use and the firewalls affected by this flow, an abstraction rule for the permission can be inferred. The utility of this abstraction rule is that it contains all the information about the permission but at a lower level, taking into consideration the topology of the network, but still being independent from the type of firewalls the organization has. 17.

(38) DEVELOPMENT This information is stored in the AbstractionRules file in XML format. It has a field containing some information as the roles name‘s, the admin‘s IP, and the companyNetwork address, needed for the concrete rules generation, it looks like this: <Info> <subjectRole>Web_Server</subjectRole> <activity>STREAMING</activity> <view>To_Internet</view> <companyNetwork>10.1.0.0/21</companyNetwork> <automaticRulesUpload>yes</automaticRulesUpload> <adminIP>10.1.3.12/32</adminIP> </Info>. And then the fields containing the data relevant to each concrete firewall, here is the information relevant to two firewalls: <Firewall IP="10.1.2.1/32" name="FW_1"> <sourceIP>10.1.1.0</sourceIP> <sourceMask>21</sourceMask> <destinationIP>internet</destinationIP> <destinationMask>0</destinationMask> <protocol>udp</protocol> <destinationPort>8000</destinationPort> <excludedViewRole roleName="FW_1_e">10.8.1.1/32</excludedViewRole> </Firewall> <Firewall IP="10.1.2.2/32" name="FW_2"> <sourceIP>10.1.1.0</sourceIP> <sourceMask>21</sourceMask> <destinationIP>internet</destinationIP> <destinationMask>0</destinationMask> <protocol>udp</protocol> <destinationPort>8000</destinationPort> </Firewall>. It is important to remark that not every firewall has the same amount of information, for example, in this case, «FW_1», has the excludedViewRole tag, this has been done because that firewall is the first one the traffic would go through, so, if it is the strictest one, the rest of the firewalls do not need that information, thus optimizing the system. This advantage will become more noticeable when the concrete rules are generated as each firewall will only have the needed rules, avoiding them unnecessary workload. Now it‘s time to translate the rules to an understandable firewall language, in this case, it is done with Iptables, but it could be done for any type of firewalls with the correct parser. 18.

(39) 3.1. HIGH LEVEL TO LOW LEVEL TRANSLATION FUNCTIONALITY The module takes the information in the AbstractionRules file and generates a chain for each permission personalized to each firewall, then a file is created for each one with the concrete Iptables commands. Here is an example: 1 iptables -N FW_1-SSH-To_Admin 2 iptables -A FORWARD -s 111.222.100.1/32 -p tcp --dport 22 -j FW_1-SSH-To_Admin 3 iptables -A FW_1-SSH-To_Admin -d 111.222.2.20/32 -j ACCEPT. This example is very simple but useful to explain how chains work: 1. The first line creates the chain called «FW_1-SSH-To_Admin», being the name the concatenation of the Role, the activity and the view names. Before continuing is important to mention that Iptables has three main chains: Input chain: It is the chain used when the traffic destination is the machine itself. Output chain: It is the chain used when the traffic is generated in the machine and exiting it. Forward chain: It is the chain used when the traffics enters through a network interface and want to exits through another. This is the relevant one in this system. 2. The second line adds the previously created chain to the forward chain and, doing so, redirects to it the traffic whose source IP is, in this case «111.222.100.1/32» (which in this case is the address of the firewall called «FW_1») and uses the port 22 of the protocol TCP. 3. Once the traffic has entered the new chain, called in this case «FW_1-SSH-To_Admin» it is faced with the restrictions defined in the third line, being that if the destination address is 111.222.2.20/32 (which in this case is the Admin‘s IP), the traffic is accepted and thereby can go through. If not, although not explicitly written, it would go back to the forward chain, and maybe entering other possible chains, if there are not any chain that accepts it the traffic follows the default Forward chain policy, which is going to be drop, and thus discarded. Here is a more complete example:. 19.

(40) DEVELOPMENT. 1 2 3 4 5 6. iptables iptables iptables iptables iptables iptables. -N -A -A -A -A -A. Private-PING-To_Internet FORWARD -s 10.1.3.0/24 -p Private -PING-To_Internet Private -PING-To_Internet Private -PING-To_Internet Private -PING-To_Internet. icmp -j Private -PING-To_Internet -s 10.1.3.12/32 -j RETURN -d 10.8.1.1/32 -j RETURN -d 10.1.0.0/21 -j RETURN -j ACCEPT. In this chain we want to allow pings from the Private network to the Internet. Considering Internet id any IP address except the ones corresponding to the organization. 1. The chain is created with the name of the subjectRole, then the Activity and in the last place, the view. If it has more than 28 characters it is shortened. 2. Then it is associated with the forward one by the packets coming from the Private subnetwork (10.1.3.0/24) and using the ICMP protocol. 3. The third line is used because the Admin (with IP 10.1.3.12/32) was an exclusion role from the role private, so if the traffic is generated by it, it is returned to the forward chain. 4. The fourth line returns the traffic if it is going to the network‘s interface of the firewall connecting the organization to Internet, because the role Internet has that role excluded, as that interface IP would not be considered Internet. 5. The fifth line is where the whole organization‘s address is used, returning the traffic to the forward chain if it is trying to reach any IP inside the organization, as it would not be considered Internet. 6. Finally, if the traffic has not been returned to the forward chain, it is accepted and can go through the firewall. So, ultimately, this functionality allows to generate from a high-level written security policy an abstract set of rules according to the network‘s topology and, finally, creating a file for each firewall with the Iptables‘s commands required to implement the policy. In essence, it allows an administrator to write a security policy in a way that is independent of the type of the security enforcement elements the organization has.. 20.

(41) 3.2. AUTOMATIC INTRUSION RESPONSE FUNCTIONALITY. 3.2.. Automatic Intrusion Response Functionality. With few additions, the system is able to read alert messages sent by an IDS (Intrusion Detection System) and update all the security policy of the organization accordingly. When an intrusion is detected an alert is sent via TCP protocol to the administrator‘s PC, where a socket is reading the incoming information. Depending on the type of intrusion, the system changes the risk of the organization, therefore reading a new set of permissions and doing the high to low level translation as explained in the former section. Another addition is to have a Configuration module, which configures the SSH to avoid asking for human interaction by helping the administrator adding the firewalls to the list of known hosts in the SSH folder, in order to avoid a message, which would pause the program. Then sends the public key of the administrator to all the firewalls to avoid being asked for the password when an SSH access is requested. Hence allowing the translation functionality to run uninterrupted when discovering the firewalls involved by the new set of rules. Finally, an Automatic Rules Uploader has been added which takes the rules written for each firewall and sends them via SSH, that is also why the Configuration module is key, in order to make this process without any human interaction, ultimately adapting the organization‘s network security to the cyber threats in real time. Below is a more detailed explanation of the additions needed to create this functionality:. 3.2.1.. Configuration Module. This module has to be executed in the administrator‘s PC. Is going to add all the interfaces of the firewalls to the known hosts list using ssh-keyscan[16]. The command looks like this: ssh-keyscan -t rsa "+ip+" >> "+System.getenv("HOME")+"/.ssh/known_hosts. The «ip» field is filled with the IPs of the interfaces of the organization‘s firewalls. The 21.

(42) DEVELOPMENT ssh-keyscan gathers all the RSA public keys and adds them to the kwnow_hosts file avoiding the appearance of this message: The authenticity of host '<host>' can't be established. ECDSA key fingerprint is SHA256:TER0dEslggzS/BROmiE/s70WqcYy6bk52fs+MLTIptM. Are you sure you want to continue connecting (yes/no)?. Which would otherwise pause the program till the question is answered manually. Then, it is going to generate an RSA pair of keys, the public one and the private if they have not been already generated, using ssh-keygen[17] as shown in Fig.7. Figure 7 : Configuration module asking for password information. As can be seen in the image, the user is going to be prompted with a question and, depending on the response, it is going to sent the keys one by one or all together. If all the firewalls have the same password then the administrator can answer with «y» and is going to be asked for the password. Then, it is going to send the previously generated public RSA key to each firewall with the OpenSSH tool ssh-copy-id[18]. When the password is sent, each firewall is going to ask for its password in order to accept 22.

(43) 3.2. AUTOMATIC INTRUSION RESPONSE FUNCTIONALITY the key. So to avoid human interaction, the sshpass command is used, which will answer automatically with the password previously introduced. In Fig.8 the described process can be seen.. Figure 8 : Configuration module sending SSH keys to firewalls. The other possibility is that the firewalls have different passwords, which is the most secure one. In this case the program will use ssh-copy-id as well, but asking the password for every firewall to the user, helping him by telling the name of it, as shown in Fig.9. Figure 9 : Configuration module asking for individual passwords. Finally, the administrator is going to be asked with the question in Fig.10. Figure 10 : Configuration module setting up all the firewalls. If the answer is «y», then the Forward chains of the firewalls are going to be set to DROP, blocking any packages to go through. Therefore, adding a rule, which allows 23.

(44) DEVELOPMENT the administrator to upload the rest of the rules to the firewalls by SSH using the default port (22). It is important to mention that this rule is added: iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT. It allows traffic in both directions, matching the replies with the allowed packets and letting them through. If it is not written then the traffic only can go in one direction, which is not very useful, as for example, TCP protocol uses ACKs. If the answer is negative, the program will end having sent the administrator‘s SSH key to all the firewalls and added all of them to the known hosts file, avoiding from now on in a secure way any human interaction when an SSH connection is made.. 3.2.2.. Automatic Rules Uploader Module. This is the script in charge of reading the files containing all the rules created for each firewall and uploading them. At first it deletes the previous rules with the commands: iptables --flush iptables -X. The former one deletes all the associations of the chains to the principal chains (Input, Output and Forward). The latter one deletes all the chains except the principal ones. Now that all the Iptables rules written in the files can be uploaded to each firewall, it uses SSH to do so notifying if the process was successful or if a problem was encountered uploading them, telling the concrete firewall the problem occurred on, to allow the administrator to check its rules manually.. 3.2.3.. IDS Configuration. The IDS used is Suricata[19], which will write alerts in a log file when some conditions are met. The conditions are written in rules. The configuration file of Suricata 24.

(45) 3.2. AUTOMATIC INTRUSION RESPONSE FUNCTIONALITY which is «Suricata.yaml» has been modified to check for rules in a new file called «local.rules». A rule in this file would look like this: alert icmp any any -> 10.8.1.1 any (msg:"Alert, ping to FW1"; classtype:policyviolation; sid:1; rev:1;). This rule will make Suricata to generate an alert if a ping from any source is headed to 10.8.1.1, and the alert will be saved with its text field(msg) and other parameters useful to classify the different warnings. These alerts are written in the Suricata log called «fast.log». This log file is read by a module called Logstash[20] which sends via TCP, in this case, any changes in the log. The command to configure this functionality of Logsasth is the following one: ./usr/share/logstash/bin/logstash -e 'input { file { path => "/var/log/suricata/fast .log" } } output { tcp { host => ["hostIP"] port => ["portNumber"]} }' > /dev/ null 2>&1 &. It tells to send any changes in the «fast.log» file using TCP protocol to the machine with the «hostIP» filed and to the port selected in «portNumber».. 3.2.4.. Socket Module. This module creates a Server socket and keeps listening to it. It is used to allow the communication between the IDS (Intrusion Detection System) and the administrator’s PC via the organization network. It analyzes the information of the incoming messages, which could be the text of the alert, or the alert level or anything agreed on with the IDS alert generator. Depending on the information of the message it will decide the action to take, for example, increasing or decreasing the risk of the organization or not and if so to which level. These three modules are integrated within the translation functionality allowing to change the security policy automatically adapting it to the current context of the organization in real time.. 25.

(46) DEVELOPMENT. 26.

(47) 4 Validation. The system has been tested in two scenarios, a simpler one and a more complex one. Both scenarios have been created using the virtualization software VNX[21]. A simple bash script has been made to start the scenarios and to configure the NAT allowing the virtualized machines to access Internet to make the scenarios as realistic as possible.. #!/bin/bash sudo vnx -f $1.xml -v -t sudo vnx_config_nat INTERNET enp0s3.

(48) VALIDATION. 4.1.. Scenario 1. The network simulated in this scenario is in Fig.11:. Figure 11 : First scenario network topology. 28.

(49) 4.1. SCENARIO 1 This topology is a common one when the company wants to offer services accessible from the Internet, like Web services in this case. Thus DMZ (Demilitarized Zone) can be accessed through certain protocols and ports allowed in the External Firewall. Nonetheless, the MZ has very important assets and therefore is a stricter area where access is much more restricted and is monitored by the Internal Firewall.. 4.1.1.. Test case 1: Proof of Concept. The first task to do when testing the system is running the Configuration module to allow the administrator‘s PC to access the firewalls via SSH without human interaction as described before. Once this has been done, the system is ready to load the permissions of the chosen risk level. In this example the initial risk is going to be 0, which is the lower one. At this risk there is going to be written 2 permissions: The first one allows PC1 making a ping to Web Server 1 to check if the machine is up. The second one allows the Internal network(MZ) to access the Internet using the ports 80, 8080 and 443 in order to enable HTTP and HTTPS communication to external web services, except the Administrator, since it would not be safe praxis. This policy could be written directly in the Permission file in XML format or using the provided GUI. In Fig.12 the relevant ones can be seen.. Figure 12 : Permissions of the Proof of Concept test case. There are four roles appearing in total in the permissions: Web server 1, PC1, MZ and Internet. They can also be created using the GUI. They would look like in Fig.13 29.

(50) VALIDATION. Figure 13 : Roles of the Proof of Concept test case. There are two activities, PING and WEB, each one defining the protocol and the ports in the second one as can be seen in Fig.14. Figure 14 : Activities of the Proof of Concept test case. The views are the destination roles which are the Web server 1 and Internet Fig.15 30.

(51) 4.1. SCENARIO 1. Figure 15 : Views of the Proof of Concept test case. Finally, the system needs three more inputs in the info section at the permissions file. They are the initial risk of the organization, its network subnet and the automatic rules uploader option: <Info> <automaticRulesUpload>yes</automaticRulesUpload> <initialCompanyRiskLevel>0</initialCompanyRiskLevel> <companyNetwork>10.1.0.0/22</companyNetwork> </Info>. Now that all the information the system needs is filled, the translation module can be executed, generating abstract rules for each concerned firewall and then deriving them to concrete Iptables rules. As the automatic upload option is set to «yes», the rules are going to be implemented in each firewall in real time. Here is how the AbstractionRules file looks like for the first permission: <Firewalls> <Info> <subjectRole>PC_1</subjectRole> <activity>PING</activity> <view>To_Web_server_1</view> <companyNetwork>10.1.0.0/22</companyNetwork> <automaticRulesUpload>yes</automaticRulesUpload> <adminIP>10.1.3.12/32</adminIP> </Info> <Firewall IP="10.1.2.2/32" name="FW_intern"> <sourceIP>10.1.3.11</sourceIP> <sourceMask>32</sourceMask> <destinationIP>10.1.2.12</destinationIP> <destinationMask>32</destinationMask> <protocol>icmp</protocol> </Firewall> </Firewalls>. 31.

(52) VALIDATION Here are the two chains created due to the two permissions that affects the Internal Firewall: iptables -N PC_1-PING-To_Web_server_1 iptables -A FORWARD -s 10.1.3.11/32 -p icmp -j PC_1-PING-To_Web_server_1 iptables -A PC_1-PING-To_Web_server_1 -d 10.1.2.12/32 -j ACCEPT. iptables -N MZ-Web_HTTP-To_Internet iptables -A FORWARD -s 10.1.3.0/24 -p tcp --match multiport --dports 80,8080,443 -j MZ-Web_HTTP-To_Internet iptables -A MZ-Web_HTTP-To_Internet -s 10.1.3.1/32 -j RETURN iptables -A MZ-Web_HTTP-To_Internet -s 10.1.3.12/32 -j RETURN iptables -A MZ-Web_HTTP-To_Internet -d 10.8.1.1/32 -j RETURN iptables -A MZ-Web_HTTP-To_Internet -d 10.1.0.0/22 -j RETURN iptables -A MZ-Web_HTTP-To_Internet -j ACCEPT. This is the only chain created for the only permission affecting the External Firewall: iptables -N MZ-Web_HTTP-To_Internet iptables -A FORWARD -s 10.1.3.0/24 -p tcp --match multiport --dports 80,8080,443 -j MZ-Web_HTTP-To_Internet iptables -A MZ-Web_HTTP-To_Internet -d 10.1.0.0/22 -j RETURN iptables -A MZ-Web_HTTP-To_Internet -j ACCEPT. As can be seen, the rules are only inferred to the concerned firewalls. That is why, the chain «PC_1-PING-To_Web_server_1» is only written for the Internal Firewall, who is the one monitoring that traffic. This chain allows the IP 10.1.3.11 which belongs to the PC_1 to use the ICMP protocol over 10.1.2.12. The other chain is «MZ-Web_HTTP-To_Internet» and concerns the two firewalls. Here can be seen that the firewall who is going to be the first one managing the traffic, is the stricter one, instead of replicating that to all the firewalls which would be unnecessary, thus, optimizing the system. In this case it has three more rules, in charge of denying access to the excluded roles, which in this case are the interfaces of the firewalls and the Administrator‘s PC. That traffic is returned to the FORWARD chain to possibly be checked against other chains.. 32.

(53) 4.2. SCENARIO 2. 4.2.. Scenario 2. The network simulated in this scenario is in Fig.16. Figure 16 : Second scenario network topology. As it can be seen, this is a much more elaborated scenario representing the possible topology of a larger organization, with different departments and five firewalls. In such a large network it is where the individual management of the security elements gets very complex and it is when the utility of the presented system becomes enhanced. 33.

(54) VALIDATION 4.2.1.. Test case 1: Big roles. As explained before, the roles can have any size, so in this scenario the first rule is going to allow all the organization except the Data Base subnetwork(from now on BBDD) and the Administrator PC to access Internet to receive a streaming signal from other organization, using the UDP port 2343. In Fig.17 the definition of the roles for this test case can be found.. Figure 17 : Roles of Big roles test case. The role «Organization» contains all the IPs of the conglomerate and excluded the BBDD department and the Admin PC. The activity looks like this Fig.18 34.

(55) 4.2. SCENARIO 2. Figure 18 : The activity of Big roles test case. The name is «STREAM» and is defined by the use of 2343 port with the UDP protocol. The view would be this Fig.19. Figure 19 : Views of Big roles test case. And, finally, the permission is shown here Fig.20. Figure 20 : Permissions of Big roles test case. This permission will be loaded if the organization is at risk level 0, which is going to be this case. In this scenario the Info section of the Permissions file is: <Info> <automaticRulesUpload>yes</automaticRulesUpload> <initialCompanyRiskLevel>0</initialCompanyRiskLevel> <companyNetwork>10.1.0.0/21</companyNetwork> </Info>. 35.

(56) VALIDATION As the role «Organization» concerns all the firewalls, rules have been generated for all of them, here is the two rules for Firewall 1 and 5: Firewall 5: iptables -N Organization-STREAM-To_Internet iptables -A FORWARD -s 10.1.0.0/21 -p udp --dport 2343 -j Organization-STREAMTo_Internet iptables -A Organization-STREAM-To_Internet -s 10.1.5.0/24 -j RETURN iptables -A Organization-STREAM-To_Internet -s 10.1.3.12/32 -j RETURN iptables -A Organization-STREAM-To_Internet -d 10.1.0.0/21 -j RETURN iptables -A Organization-STREAM-To_Internet -j ACCEPT. In this chain, the firewall is allowing all the traffic from the organization network to the Internet, refusing the streams that are coming from the BBDD department, the Administrator‘s PC and also if it is trying to access any network element inside the organization. The rest of the firewalls contain the same chain except the Firewall 1. Firewall 1: iptables -N Organization-STREAM-To_Internet iptables -A FORWARD -s 10.1.0.0/21 -p udp --dport 2343 -j Organization-STREAMTo_Internet iptables -A Organization-STREAM-To_Internet -s 10.1.5.0/24 -j RETURN iptables -A Organization-STREAM-To_Internet -s 10.1.3.12/32 -j RETURN iptables -A Organization-STREAM-To_Internet -d 10.8.1.1/32 -j RETURN iptables -A Organization-STREAM-To_Internet -d 10.1.0.0/21 -j RETURN iptables -A Organization-STREAM-To_Internet -j ACCEPT. In this case, the chain of this firewall is very similar to the addition of blocking the traffic trying to access its external interface (10.8.1.1) because it is in the exclusion roles list of the Internet role and the algorithm infers that it is only necessary to write the rule in this firewall.. 4.2.2.. Test case 2: Path discovery. Another test case of the translation functionality it is going to be an access from the payroll department to the BBDD server to check if the rules are only inferred to the concerned firewalls. In this case the affected firewalls would be FW_3, FW_4 and FW_5. So, the rule would allow the payroll subnetwork to access via TCP using the port 6001 to the BBDD server. The important roles in this test case are Fig.21 36.

(57) 4.2. SCENARIO 2. Figure 21 : Roles of Path discovery test case. The role Payroll represents all the payroll department and excludes the network interface of the firewall 4 which would be otherwise included in the role. The activity is in Fig.22. Figure 22 : Activity of Path discovery test case. This activity allows the database server to be consulted at the port 6001 with TCP. The view is shown here Fig.23. Figure 23 : View of Path discovery test case 37.

(58) VALIDATION In Fig.24 the definition of the permission can be seen.. Figure 24 : Permission of Path discovery test case. As expected, the system has only inferred the rules to the three firewalls which will manage the traffic. The concrete Iptables rules for each one are: Firewall 4: iptables -N Payroll-CONSULT-To_BBDD_Server iptables -A FORWARD -s 10.1.6.0/24 -p tcp --dport 6001 -j Payroll-CONSULTTo_BBDD_Server iptables -A Payroll-CONSULT-To_BBDD_Server -s 10.1.6.1/32 -j RETURN iptables -A Payroll-CONSULT-To_BBDD_Server -d 10.1.5.11/32 -j ACCEPT. Firewalls 3 and 5: iptables -N Payroll-CONSULT-To_BBDD_Server iptables -A FORWARD -s 10.1.6.0/24 -p tcp --dport 6001 -j Payroll-CONSULTTo_BBDD_Server iptables -A Payroll-CONSULT-To_BBDD_Server -d 10.1.5.11/32 -j ACCEPT. As explained before, the first traffic managing the traffic, which is firewall 4, is the strictest one and does not allow the flow of traffic coming from the firewall network interface. Now its time to check the AIRS functionality, which will allow to adapt the company security policy in real time to the threads detected by and IDS.. 4.2.3.. Test case 3: Quarantine. The first test is going to be the detection of an employee from the Internal department trying to access a malicious site and getting infected. To prevent any further damage, the department is going to be quarantined. This attack will occur when the «PC Internal» visits a web site and gets infected with malware, who is going to try to leak 38.

(59) 4.2. SCENARIO 2 information using via FTP using the TCP port 20 to a Russian IP. The IDS is going to detect that IP as suspicious and send an alert. The initial state of the organization is having the risk at level 0. When the alert is triggered, it will be analyzed and the risk will be increased to level 2, isolating the internal department, as can be seen with these permissions Fig.25. Figure 25 : Permissions of Quarantine test case. Once the administrator has SSH access to all the firewalls without being asked for the password the system is going to load the permissions at the level 0, do the translation process, upload the concrete rules to the necessary firewalls, and open a socket to receive the alerts from the IDS. In Fig.26 it is shown how the Firewall 2 Iptables module is configured before the “PC Internal” gets infected.. 39.

(60) VALIDATION. Figure 26 : Firewall 2 Iptables rules before the infection in Quarantine test case. As can be seen in the figure all the chains derived from the policy described before are written with the exception of Internet accessing the DMZ, because that traffic is going to be managed only by firewall 1. To detect the intrusion, an IDS is deployed in FW monitoring all the traffic entering and going out of the organization. Checking malicious IPs sites has created a rule which looks like this: alert tcp 10.1.3.0/24 any -> 83.223.12.3 20 (msg:"Alert, FTP to suspicious IP, level 2"; classtype:policy-violation; sid:2; rev:2;). This rule tells the IDS to generate an alert when any traffic goes out with the default port of FTP with the malicious IP as destination. The alert will be saved in a log file called fast.log Then, the module Logstash is going to send that alert via TCP to the port 2000 of the Administrator‘s PC, where it will be analyzed by the system to determine if the risk has to be changed or not. The IDS rule is going to be triggered executing the following command in PC Internal: iperf -c 83.223.12.3 20 -p 20. 40.

(61) 4.2. SCENARIO 2 Finally, analyzing the potential thread, the system is going to increase the risk level to two, loading the new permissions, and therefore, isolating the Internal department. After all the process, the new rules uploaded in firewall 2 will be Fig.27. Figure 27 : Firewall 2 Iptables rules after the infection in Quarantine test case. As it can be seen, all the rules allowing traffic to and from the Internal department have been deleted.. 4.2.4.. Test case 4: Dishonest Employee. The last demonstration is going to be an internal attack to the BBDD Server and how the system is going to detect it and automatically change the organization security policy to protect the data. The attack will be originated from a PC situated in the Payroll department because an employee is angry about the last salary increase. The dishonest employee is going to try to access the BBDD Server from «PC Payroll» and then delete all the information. The employee‘s boss fearing this could happen has told the IT department to change the BBDD Server management password but is still afraid a coworker tells him the new one. The firewall 5 will have and IDS running inspecting the traffic. When the intrusion is detected, it will be considered as potentially dangerous and will increase the organization risk level to 7. The rule of Suricata in charge of generating the alerts is:. 41.

(62) VALIDATION. alert tcp 10.1.6.0/24 any -> 10.1.5.11 15532 (msg:"Alert, Reiterated failed BBDD log in, level 7"; flags: S+; threshold: type both, track by_src, count 2, seconds 30; classtype:policy-violation; sid:2; rev:2;). This rule is triggered if a machine at the payroll department (10.1.6.0/24) sends two or more SYN packets in less than 30 seconds to the BBDD Server (10.1.5.11) using the TCP port 15532. The organization has its risk at level 0 initially, with the following permissions Fig.28. Figure 28 : Permissions of Dishonest employee test case. At risk 0, the organization allows the Admin and Payroll department to manipulate the BBDD server and the Internal department to consult it. It also allows the firewall 5 to send the detected alerts to the administrator. In Fig.29 is explained the Iptables of the firewall 3 are set before the attack happens, when the organization is at a risk level of 0. 42.

(63) 4.2. SCENARIO 2. Figure 29 : Firewall 3 Iptables rules before the internal attack in Dishonest Employee test case. As can be seen in the picture, in this case, the firewall has to manage all the permissions written at this level, therefore, it has a chain for every permission and and additional one to allow the administrator to configure the firewalls. The attack is going to be triggered executing this command 2 times from the «PC Paytoll»: iperf -c 10.1.5.11 -p 15532. It would emulate an employee writing the incorrect password two consecutive times and thus getting the connection refused. If it is done twice in less than 30 seconds it will trigger the alert system as explained before. When the alert is generated the Logstash module is going to sent it to the Administrator‘s PC. It will increase the risk of the organization to level 7 in this case, thus, protecting the BBDD, and only leaving this 43.

(64) VALIDATION two chains in the Firewall 3 Fig.30:. Figure 30 : Firewall 3 Iptables rules after the internal attack in Dishonest Employee test case. As can be seen the only chains left are the ones that allow the admin to configure the firewalls and to receive the alerts of the IDS at firewall 5. Hence the access to the BBDD department has been restricted in real time, securing the BBDD Server and ultimately achieving the protection of the organization data.. 44.

(65) 5 Conclusions. The system proposed in this thesis aims to make organizations as secure as possible with the smallest effort. The focus has been put into making it work for any organization, with any type of network topology and with any kind of security enforcement elements. Another important objective of this project is to make the system as user friendly and automatic as possible, such as building up a GUI. The last main effort was put on making the system able to connect to an IDS so that, with that information, a risk level can be inferred and the security of the organization can be adapted in real time. The program has been developed using in Java to make it independent from the system OS, since Java programs run on the Java Virtual Machine. The language chosen to write the high-level policies is XML because it is a well standardized, and organized format. Afterwards, as it has been explained, the system generates an abstract rules document, also written in XML, which can be consulted by the user. With that document the concrete rules are generated, in this case, in plain text with the Iptables commands that each firewall has to execute. If desired, they are automatically uploaded. With the designed configuration module this process does not require human interaction. Then, with the help of an IDS the system can respond in real time to cyber threats by changing the security policy implemented. The main problems faced along the design of the project have been both the lack of information given the innovative characteristics of this implementation and the different technologies on which it relies. It has been necessary to learn about the VNX software used to create the scenarios and SSH configuration for the communication along.

(66) CONCLUSIONS the network, expand the Java knowledge already had, and more specifically the Swing library for the GUI and Java Net for the socket receiving the IDS alerts. It has been also key to learn not only how networks in real environments work, or how the Iptables firewalls work, but also how to configure the IDS Suricata and Logstash to send the alerts. One of the most challenging parts encountered has been the design of the module that discovers which are the firewalls affected given a certain traffic flow, having to design two algorithms to make it possible. The first one evaluates whether a subnetwork contains any IP of another subnetwork, which is crucial for the correct functioning of the module. The second algorithm calculates the implicated firewalls by using the first algorithm and applying it to the information retrieved by asking these firewalls their routing tables, thus, being coherent with the administration policy of the organization. It is also worth noting the effort put on the automatization of features such as the communication via SSH in a secure way or the connectivity problems a real scenario may have. To summarize, this project required transversal knowledge from several areas such as, but not limited to in-depth programming, knowledge about security elements or advanced network concepts. It also required creativity to merge all this knowledge into a fully functional solution. Nevertheless, looking at the final result, the effort has been worth it, developing a real working system tested in several scenarios under different situations and networks.. 5.1.. Achieved Goals. In this section the main features of the project and the goals achieved by them are explained:. GUI The GUI allows anyone to use the system without the need of knowing the XML format, making the writing and supervising process of the cyber security policies easier.. 46.

(67) 5.1. ACHIEVED GOALS Configuration Module This module is in charge of interconnecting all the organization firewalls to the Administrator in an easy way using SSH. Therefore, allowing the system to communicate without human interaction.. Abstract Rules Module A self-made IP algorithm is used to check if the user has properly defined the roles and permissions and also by the path finder algorithm to find out what are the concerned firewalls for a certain traffic. Ultimately, it allows the user to write policies without worrying about the network topology, the technology the firewalls use, to avoid misconfigurations in the firewalls and overall reducing the complexity.. Concrete Rules Module It transforms the abstract rules generated by the previous module to concrete Iptables rules automatically. Its main achieved goal is the translation of generic rules to a specific firewall language, in this case, Iptables.. Automatic Rules Module This module is able to upload the concrete rules to the firewalls of the organization via SSH. It allows to deploy the security policy of the organization in one click.. IDS Configuration and Socket Module The last achieved goals has been the configuration of the IDS Suricata and Logstash to generate the alerts and send them through the organization network to the socket module. The socket module analyzes the threats and decides at what risk level the organization is at, allowing the organization to respond to the threats in real time.. 47.

(68) CONCLUSIONS. 5.2.. Future Work. There are some interesting features that could be added to this project:. More advanced Rule Definition There are more parameters that could be added to a rule, some of the most used ones are: Source Port Time Burst limit Writing Logs Another interesting addition could be the possibility of selecting the security approach. So far the approach has been a restrictive one, restricting everything except what is permitted,for example, another security approach could be to allow everything except what is forbidden.. Better GUI A more interactive GUI could be developed, for example, in the permission view, when clicking in the activity name, the user could be sent to the activity definition in the Activities file.. Dynamic Policies By making a more precise alert system, the system could start generating the policies following certain parameters, an easy example, could be that if a flow has to be blocked, the system could delete the permission that allows that traffic without needing to change the organization risk level.. 48.

(69) 5.2. FUTURE WORK Framework for Concrete Rules Generator Module The approach taken in this project allows the system to be used by any type of firewall with the correct concrete rules generator. A framework could be made to facilitate the development process to anyone who wants to make a concrete rules generator for other firewall‘s languages.. 49.

(70) Appendixes. 50.

(71) I Impact of this Project. The impact of this project can be seen from four points of view: Social, Economic, Environmental, and Ethical and Professional implications. They are thoroughly described below.. A.. Social Impact. Due to the increasing concern of the population about cyber security, this project could have a remarkable impact. The companies which will use this system will have stronger security, and thus, less data breaches. They could advertise this characteristic to their consumers, making them increase their trust in these companies and in uploading their personal data to the Internet in general.. B.. Economic Impact. From the point of view of the organizations, this project allows them to use their legacy systems more often like firewalls, and therefore spend less money in new policy enforcement systems. Also they need to spend less resources in training their security experts in each firewall technology. In addition, as an Intrusion Response System able to stop cyber attacks the cost or the probability of a successful attack is smaller as their assets are more protected..

(72) IMPACT OF THIS PROJECT. C.. Environmental Impact. The environmental impact of this project is mainly related to the power consumption and also to the fabrication of the computers using this project. Regarding the impact due to the power consumption, the main hardware is going to be the machine executing the program, and the firewalls, although these machines are probably going to be installed already. As this project allows to use legacy machines, it may also reduce the greenhouse gas emissions by avoiding building new machines.. D.. Ethical and Professional Implications. The principal ethical implication of using this system aims to centralize and facilitate the creation and enforcement of security policies. Thus, it could lead to the destruction of some jobs. Nevertheless, instead of a job destruction, it could be a transformation, since the organizations would need people who create the modules for the abstract rules to concrete rules transformation.. 52.

Referencias

Documento similar

Following the introductory course, students will practice translation in various fields to learn basic knowledge, terminology and expressions specific to each

Additionally, in order to provide a mechanism for extracting high- level context from low-level information, the system allows the creation of User- defined context reasoning rules in

Therefore, it sends the speech tran- scriptions from the speech recognition module to the machine translation module and the subtitle module, and the sequence of glosses from

On the road to the Preliminary Design Review of the MAORY.. adaptive optics module

The aim of this study is to carry out the process of translation and adaptation to Spanish of the locus of control in sport’s scale for children (Tsai and Hsieh, 2015) and to

weighted mean values of the different functional traits for each grazing intensity level and year, 694. in productive (left) and unproductive

The information stored in each input module is (i) the associated burst target output fiber, burst offset, burst length and QoS class, (ii) the information about burst allocation,

The qualitative scale used for the integrity assurance at transport level metric en- compasses three levels: Low, Medium, and High. Each of these levels represents the