The key takeaway I find in this article is the conflicts in security policy. With the development of network technology and society, there are more and more network attacks, and information security has become global attention. Different network security equipment and technical methods have emerged in response to different network attacks, and firewalls are important network security devices. When multiple different security policies are implemented on the firewall, policy conflicts will affect the network’s network’s network’s network’s normal operation and threaten network security.
Security policies in actual systems often exhibit conflicts and redundancy. A high-level and complete security policy representation of the availability of support service construction analysis can identify these anomalies and may suggest corrective strategies. The contradiction in this policy is also called a formal conflict. Due to positive authorization and negative authorization in the same policy applied to the same access request, the conflicts that have occurred are due to positive authorization. Another type of conflict is derived from the security policy definition of the constraints that authorization must satisfy. One important type of constraint is the separation of duties (SoD). These constraints follow common best practices, and sensitive combinations of permissions should not be held by the same person to avoid violating business rules. The purpose of this restriction is to prevent fraud by spreading the responsibility and power of a certain action or task, so the participation of more than one person is required, thereby increasing the risk of committing fraud to individuals.
This document mainly introduces the conflict in a security policy and analysis of conflict detection for network policies. A typical top-down representation of the protection of an information system consist five layers: Security requirements, Abstract policies, Executable policies, Policy enforcement mechanisms, and Enforced policies. Conflicts can be divided into two categories: (1) intrapolicy conflicts that may exist within a single policy and (2) interpolicy conflicts that may exist between at least two policies. And each category also can divide into subcategories: contradictory, redundant, and irrelevant. Contradictory conflicts arise when the two authorizations are said to be incompatible. Redundant conflicts arise when an authorization is dominated by other authorizations and does not contribute to the policy. And irrelevant conflicts will happen when specification of the elements of the authorizations cannot lead to activation of all of the authorizations.
Hi Xinyi, I agree with your point of view. The conflict between security policy and analysis of conflict detection for network policies is the main point of the discussion. The relationship between security requirement and policies are one goes for a larger concept and the other lays out the detail of the actual process.
Hi Xinyi,
your point is amazing. Redundant conflict means that one operation is controlled by another authorization. Deleting this authorization does not modify the behavior of the system. When a behavior is allowed by authority and is denied by another authority, conflict arises. There are several ways to solve such conflicts. First, the deny override algorithm ensures that priority is granted to deny authorization. Second, you can use the first applicable method to ensure priority handling of the first generation of authorization.
One of the key points I learned from the chapter “Detection of Conflicts in Security Policies” is network security conflict and detection exception or firewall configuration conflict. Firewall is the core element of network security. However, if the firewall is not configured correctly, the firewall may become the main vulnerability. Therefore, firewall filtering rules should be sorted and distributed correctly to prevent firewall policy exception. There are three ways to ensure the accuracy of policies in the firewall. These three methods are manual testing, query based methods, and conflict and exception analysis tools.
Hi Wenyao
As per your points, contradictions or ambiguities in the policy specification may lead to unforeseen anomalies when implementing rules specified by policies. If such anomalies exist on firewall policies, it causes a big security vulnerability to the entire network system.
One conflict that really stuck out to me from this article is the problems with the separation of duty. From class, we talked about how most times, people will speak up when they lack access(least privilege) and not when they have additional access. Before organizations realized the dangers of granting too much access, employees were allowed access even after they may be done with the project or they just simply no longer need it in their business role. Companies should definitely invest in IAM systems or something similar to be able to track, what user role needs this access as it seems fit for their group. If the role is a developer, they should not have access to the production environment to deploy the code. If the person is writing the checks, they shouldn’t have the access to process these checks.
Companies should apply the concept of least privilege, if an employee needs it eventually, an access request must be put in, the approver will have to examine their previous access and only grant access if there is a clear divide in permissions. User access recertifications should also be done on a scheduled basis to ensure if there is a spillover, it is discovered and mitigated immediately.
Policy enforcement mechanisms stuck out as a point of interest from this reading, a separating factor for policies from how they are enforced. It is evident that early identification of anomalies can be achieved using formal representation. O the other hand, policy analysis at high levels brings out anomalies and suggests their corrections. These anomalies, in form of conflicts can be categorized as intra-policy, -exist within one policy of inter-policy, -exist in two or more policies. They are all subcategorized as Contradictory, redundant, or irrelevant.
Security requirements looks at a boarder perspective of the business concept of the information technology requirement. It ignore the detail of what kind of tool to use or what how does the tool integrates with other system and tools. This layer uses terminology and levels of detail typical of managers that are commonly expressed using natural language. Formal consistency verification cannot be applied automatically to security requirements, human intervention will be required to complete the task. Policies is a representation of how business mapped to the system used for service provisioning. Policies can be used in different level, so it needs a higher -level specification approach to be adopted, possibly associated with a software tool, that supports the generation of lower-level representation. Under the policies, there is abstract policies. Abstract policies provide a formal representation of access control and its behavior. It is declarative, because it does not specify the actual mechanism of the process, it only lay out the rules of the target purpose.
Policy based network management has been widely used in the field of network security management because of its flexibility, ease of use, automation and so on. A policy is a set of constraining rules configured by a network administrator to protect system security. It is found that the network topology is often neglected in the current network security policy model. However, the network topology is an important consideration in policy-based network management, and the change of network topology will make the network management policy also change. At the same time, as the structure of the network becomes more and more complex, the configuration of the policy will inevitably have conflicts. Therefore, almost all policy-based network security models need to detect policy consistency and eliminate conflicts existing in the policy system, otherwise the system will have security vulnerabilities. Current policy conflict detection methods are divided into single point detection and global detection, both of which have defects. If a single point detection is carried out, only the internal policy conflicts of network devices can be detected, but not the policy conflicts among network devices. Global detection, on the other hand, aggregates the rules of all devices for all detection, which may result in conflicting false positives. Because in a large network, it makes perfect sense to have inconsistent policies between different paths.
After reading this, it reminded me of what I see daily. In my line of work, I typically deal with firewalls dropping packets or performing stateful packet inspections while we are sending information to and from our application. These firewalls can often replace parts of the packet with different headers. Our application rejects these packets and it stops functioning properly. The firewall team typically has to allow our traffic without the inspection in order to work. They aren’t happy that the firewall can’t do the inspection but eventually they whitelist our IP and Port.
Firewalls can be good and bad for organizations and applications. The firewall teams have to configure the firewalls correctly or they could leave themselves exposed. Finding conflicting policies is essential to making sure the organization stays protected.
Hi Johnathan, I agree with you as well. Firewalls can be helpful in protecting the organization but they also need to be configured properly and additional work such as whitelisting known IPs to be effective. Even on my personal computer, I keep my firewall on but because of how strictly they block outside applications, it’s a process to install “known applications” as well. If the organization is more susceptible to being attacked, having a firewall is definitely great as a buffer for outside threats, there just has to be people in charge making adjustments so they’re not blocking traffic necessary for business needs as well.
This chapter focuses on the detection of conflicts in security policies. Separation of duty (SOD) stuck out for me as one of the conflicts. Sensitive combinations of permissions should not be held by the same individual to avoid violating business rules. SOD helps prevent conflict of interest, fraud, etc. For example, individual responsible for HR should not be responsible for designing and implementing security. The chapter mentions about the role-based access control (RBAC) which restricts network access based on a person’s role within an organization. Employees are only allowed to access the information necessary to perform their job. RBAC is quite helpful if the organization has many employees and use third-party contractors as it will help in securing the company’s sensitive data.
I thought the book had a great example of one of the most common SOD’s in just about every company: Accounts Receivable (AR) and Accounts Payable (AP). Essentially, AR is responsible for the money coming into the company for services or products it provided where as AP is responsible for the money coming out of the company for paying bills or services bought. I’m sure an accountant could do both roles, however, the principal of SOD prohibits one person from holding too much power within the business process.
The separation of duty section from this reading was interesting to me as new conflicts arise from a lack of separation. These constraints follow best practices for which sensitive combinations of permissions should not be held by the same individual. The purpose of SoD is to discourage fraud by sprinkling responsibilities and duties for any action or task. By doing this it raises the risk of committing fraud as now it would require more than one individual. SoD is used for more than IT security such as banking and military sectors due to the use of such sensitive and important data. It could be compared to the checks and balances of the government as if it was not in place, one person or group of people would be able to conduct actions without the oversight of others. Role-based access control is adapted to express the constraint because the role hierarchy allows for easy oversight and management of who can do or modify what.
Hi, Austin.
I agree with you. Banking and military must have SoD, so people will be not able to take advantage to steal the confidential information that uses in violation of the law. The SoD helps the organization to monitor and restrict the employees’ activities, and this can mitigate the risk of malicious employees committing fraud.
When dealing with security policies, there are often conflicts. These conflicts are in two categories: Intra-policy conflicts and Inter-policy conflicts. For both of these conflict types, they can be further organized into Contradictory, Redundant, and Irrelevant conflicts. For contradictory conflicts, these stem from two policies that regard one ruleset that differs. The example in the reading explained this as if an employee was given read and write permissions of a file in one policy, but another policy decides that the employee shouldn’t have these permissions. Redundant conflicts is when one policy supersedes another policy in terms of ranking. This would be if someone had access to a file, but also had access to the root folder the file was contained in. Lastly is the irrelevant conflict, which means that a policy is in place but the conflict cannot occur regardless if the policy was in place or not. An example of this could be if a policy states that one cannot use a well-known port, such as FTP, but the firewall in place already disabled all problematic well-known ports.
Hi Krish,
It is very common to have contradicting inter-policies especially where privacy meets security so to say. A security policy could suggest monitoring of network traffic while a privacy policy warns of the implications of viewing certain traffic. In such cases, a compromise would seem the best option to ensure both policies are observed in some sense.
I think this categorization of conflicts is a great addition to a security plan. As we know the more detailed you get in your plan the better it is to pinpoint where an issue stems from, so if we apply this same level of thinking to potential conflicts we can slowly minimize the amount of conflicts based on their severity.
It is important to have a clear separation of duty to lower the conflicts in security policies. In order to make the authorization safe, the multiple access of sensitive combinations should not be held by the same person. If the same person owns them, the person can extract the information without permission and use this unlimited access to commit fraud. As this article mentions, the multiple access of sensitive combinations should be held by multiple users. They can monitor each other, so one user is not able to set up too low or too high a price for the nominal customer. However, there is only one user who can create and process the purchase order, and the malicious employee can take advantage to counterfeit the transactions and make the financial statement satisfied for the stakeholders. Thus, the company needs to appropriately set up the authorized access base on the job description, so they will not out of control.
Hi Cami,
Good point. The division of responsibilities can help set constraints and best practices to reduce fraud. For example, the functions of the people we can create and approve purchase orders should be separated. In addition, the change environment should be separated and developers should not be allowed to access the production environment.
I also touched on this being the most important part. The SoD and the fact that you have assigned responsibility for one thing to multiple people, this way there cant be one person who flies under all the radars. This checks and balances type setup helps decrease one of the hardest threats to stop, the insider threat. By mitigating this you can put more trust into your employees to handle this as they are help responsible not only to the company and management but also to their peers.
The conflicts in separation of duties is one of the main points that stuck out to me most. Separation of duties is a type of access control where one or more people are required to complete a specific task. This reduces the chances of fraud and malicious activities due to multiple users being involved, which essentially creates checks and balances. An example of this is deploying code on a server in the cloud. One user should be the developer who creates and maintains the code and another user for building the servers and deploying the code on the box. Additionally, there should be proper sign-offs from management before the process begins to further increase awareness. Based off of the two user’s functions, a role-based access control model can be used to ensure each user has the least amount of privilege needed to perform their daily job functions.
Hello Anthony,
Great post!
I mentioned about SOD in my post as well. No one user should be given enough privileges as there are higher changes of misusing the system. For example, an HR shouldn’t have the authority to test the software/program and a QA shouldn’t have the ability to access payroll records. You provided a good example of separating the duties of developers where one should be responsible for creating and maintaining a code while the other developer should be responsible for building the servers and deploying the code. The concept of least privilege should be applied where individuals only have access to the information they need in order to complete their job correctly.
The key take way from this articles is the separation of Duty in conflicts in security polices. An important class of constrains is separation of duty(SoD) which make sure the sensitive combinations of permissions should not be held by the same individual, to avoid the violating business rules. The purpose of this constraint is to discourage fraud by spreading the responsibility and authority for an action or task, thereby raising the risk involved in committing a fraudulent act, by requiring the involvement of more than one individual. And SoD has two main categories static SoD and dynamic SoD to balance.
I found this chapter interesting because of the various methods for detecting policy conflicts in firewall configurations and the multidimensional lens that needs to be placed within the same firewall and across the layers of firewalls that make up the firewall architecture. It is interesting how detecting firewall policy conflicts has advanced from manual checks to data queries to more artificial intelligence / machine learning techniques using tools that allow for algorithm building based on the layer the firewall is protecting and the granularity of the policy being examined.
Firewall ACL conflicts was interesting. It discussed the different types of firewalls and what part of the packet they are reading to allow or drop traffic. The basic packet filter firewalls work at the network and transport International Organization of Standardization/Open System Interconnection(ISO/OSI)layer, which makes decisions based on five fields: the Internet Protocol (IP) address and ports of the source and destination, and the IP protocol type. At the highest level of the ISO/OSI stack, there are the application firewalls. Application firewalls are usually tailored to one or more specific protocols to perform a more focused analysis. The most widespread one is the Web Application Firewall, which observes HTTP properties and fields. Theses firewalls can sense specific types of attacks such as brute force login attempts and SQL injections. Because some packets may be allowed on more than one ACL, it is important to stack the ACL’s according to the most important rule being first, as the firewall will allow a packet through on the first rule that it matches. Conflicts can occur on application firewalls if the correct service is not selected in the firewall. For example, if a rule states that any “Untrust” traffic is allowed to any server in the “Web” zone, on port 80 and 443 but no service is selected, then the firewall is not looking for HTTP/S traffic on that rule. It is essentially just a port based rule. No the attacker could send malformed packets with any kind of traffic to port 80/443 and the firewall is none the wiser. I work with application firewalls at work, and I find mis-configured rules all the time that do not specify a service (or type of traffic) to be allowed on the rule. This negates the purpose of the firewall and opens up more security holes.
Your post goes to show that the firewalls in which we set up are only as secure as we make them. The assumption that nothing bad will happen if port 80/443 are open because they are a needed and well-known port can be detrimental to the firewall and organization’s system. In addition to port-based rules, another method or two should be implemented to greater mitigate risk.
This document highlights the importance and ways to detect and manage conflicts in security policies. This is important especially for both the research and industrial communities. The document’s prime goal was to focus on the detection of conflicts, the executable policies, and the detection of policy conflicts within the computer networks, with greater industrial support output. Support in industrial products can be expected to appear in the near future for security policies in other scenarios and at a variety of abstraction levels. The document also proposed the discussion of Semantic Web technology and how it can be applied to these tasks, offering a strategy that can be successful for the deployment in real systems.
One of the key take-away’s in this chapter is the criticality of Segregating Duties. (SoD). This is an effective way of creating rules where user A cannot perform conflicting actions within the same process. Using these types of constraints require a good understanding of each business process so that a security designer is able to find inconsistencies in the policy. At times addressing these inconsistencies may require revisions of policy, limiting user roles and responsibilities or modifying the specifics around the constraints to tight or loosen the reigns around it. There are two types of SoDs — static and dynamic. . Static surrounds very specific roles that are very specifically defined as to what each can or cannot do. The dynamic roles consider the timing of the action. where there is a strong reliability on the system to keep ‘precise track of each task”.
Segregation of Duties is a key tool used in the finance industry or in manufacturing where certain transactions require approval from another entity to be processed. They are used primarily to raise the risk that is involved in performing fraudulent transactions, effectively reducing a potential conflict of interest.
Hi, Vanessa, I totally agree with your points, I also mentioned the separation duties in my comment. The separation of duty(SoD) could make sure the sensitive combinations of permissions should not be held by the same individual, to avoid the violating business rules in some extent.
Some of the main gains of this reading include noticing the differences between abstract strategies and executable strategies, and the importance of detecting conflicts in authorization and access mechanisms. The abstract policy attempts to define the required behavior but does not specify a detailed mechanism for forcing the behavior. The executable policy is configured in detail and is directly understood by the system used. There are tools and methods for detecting conflicts. This reading provides a very good and easy-to-understand example to show how the unknown conflict becomes a security problem, as shown in Figure 55.3. User privileges may be restricted, such as policies, which can access certain files in the system, but if they can access other folders or regions containing the same type of files or information, what should they do? This basically means that security policies become useless. We must realize that there are these types of conflicts in our environment. I also discovered how these concepts and materials fit with firewall and the semantic web.
I enjoyed your summary once again. It seems that having executable strategies is more valuable than having abstract strategies. Having abstract policies could cause security problems. It’s important for the firewall team to develop executable strategies when creating the rules and separation of duties.
A key takeaway from this section is topic of separation of duties. Separation of duties is the concept of having more than one person required to complete a task. In business the separation by sharing of more than one individual in one single task is an internal control intended to prevent fraud and error. Some examples of real life scenarios of separation of duties:” Same person should not be able create a vendor and pay invoices”, Hiring employees and paying salaries and Same person should not prepare bank deposits and verify cash receipts.
A solution to this issue is Role Based Access control. Role Based Access Control is an approach to restricting system access to authorized users. It is used by the majority of enterprises with more than 500 employees. RBAC lets employees have access rights only to the information they need to do their jobs and prevents them from accessing information that doesn’t pertain to them.
Zibai Yang says
The key takeaway I find in this article is the conflicts in security policy. With the development of network technology and society, there are more and more network attacks, and information security has become global attention. Different network security equipment and technical methods have emerged in response to different network attacks, and firewalls are important network security devices. When multiple different security policies are implemented on the firewall, policy conflicts will affect the network’s network’s network’s network’s normal operation and threaten network security.
Security policies in actual systems often exhibit conflicts and redundancy. A high-level and complete security policy representation of the availability of support service construction analysis can identify these anomalies and may suggest corrective strategies. The contradiction in this policy is also called a formal conflict. Due to positive authorization and negative authorization in the same policy applied to the same access request, the conflicts that have occurred are due to positive authorization. Another type of conflict is derived from the security policy definition of the constraints that authorization must satisfy. One important type of constraint is the separation of duties (SoD). These constraints follow common best practices, and sensitive combinations of permissions should not be held by the same person to avoid violating business rules. The purpose of this restriction is to prevent fraud by spreading the responsibility and power of a certain action or task, so the participation of more than one person is required, thereby increasing the risk of committing fraud to individuals.
Xinyi Zheng says
This document mainly introduces the conflict in a security policy and analysis of conflict detection for network policies. A typical top-down representation of the protection of an information system consist five layers: Security requirements, Abstract policies, Executable policies, Policy enforcement mechanisms, and Enforced policies. Conflicts can be divided into two categories: (1) intrapolicy conflicts that may exist within a single policy and (2) interpolicy conflicts that may exist between at least two policies. And each category also can divide into subcategories: contradictory, redundant, and irrelevant. Contradictory conflicts arise when the two authorizations are said to be incompatible. Redundant conflicts arise when an authorization is dominated by other authorizations and does not contribute to the policy. And irrelevant conflicts will happen when specification of the elements of the authorizations cannot lead to activation of all of the authorizations.
Ting-Yen Huang says
Hi Xinyi, I agree with your point of view. The conflict between security policy and analysis of conflict detection for network policies is the main point of the discussion. The relationship between security requirement and policies are one goes for a larger concept and the other lays out the detail of the actual process.
Haozhe Lin says
Hi Xinyi,
your point is amazing. Redundant conflict means that one operation is controlled by another authorization. Deleting this authorization does not modify the behavior of the system. When a behavior is allowed by authority and is denied by another authority, conflict arises. There are several ways to solve such conflicts. First, the deny override algorithm ensures that priority is granted to deny authorization. Second, you can use the first applicable method to ensure priority handling of the first generation of authorization.
Wenyao Ma says
One of the key points I learned from the chapter “Detection of Conflicts in Security Policies” is network security conflict and detection exception or firewall configuration conflict. Firewall is the core element of network security. However, if the firewall is not configured correctly, the firewall may become the main vulnerability. Therefore, firewall filtering rules should be sorted and distributed correctly to prevent firewall policy exception. There are three ways to ensure the accuracy of policies in the firewall. These three methods are manual testing, query based methods, and conflict and exception analysis tools.
Humbert Amiani says
Hi Wenyao
As per your points, contradictions or ambiguities in the policy specification may lead to unforeseen anomalies when implementing rules specified by policies. If such anomalies exist on firewall policies, it causes a big security vulnerability to the entire network system.
Mei X Wang says
One conflict that really stuck out to me from this article is the problems with the separation of duty. From class, we talked about how most times, people will speak up when they lack access(least privilege) and not when they have additional access. Before organizations realized the dangers of granting too much access, employees were allowed access even after they may be done with the project or they just simply no longer need it in their business role. Companies should definitely invest in IAM systems or something similar to be able to track, what user role needs this access as it seems fit for their group. If the role is a developer, they should not have access to the production environment to deploy the code. If the person is writing the checks, they shouldn’t have the access to process these checks.
Companies should apply the concept of least privilege, if an employee needs it eventually, an access request must be put in, the approver will have to examine their previous access and only grant access if there is a clear divide in permissions. User access recertifications should also be done on a scheduled basis to ensure if there is a spillover, it is discovered and mitigated immediately.
Humbert Amiani says
Policy enforcement mechanisms stuck out as a point of interest from this reading, a separating factor for policies from how they are enforced. It is evident that early identification of anomalies can be achieved using formal representation. O the other hand, policy analysis at high levels brings out anomalies and suggests their corrections. These anomalies, in form of conflicts can be categorized as intra-policy, -exist within one policy of inter-policy, -exist in two or more policies. They are all subcategorized as Contradictory, redundant, or irrelevant.
Ting-Yen Huang says
Security requirements looks at a boarder perspective of the business concept of the information technology requirement. It ignore the detail of what kind of tool to use or what how does the tool integrates with other system and tools. This layer uses terminology and levels of detail typical of managers that are commonly expressed using natural language. Formal consistency verification cannot be applied automatically to security requirements, human intervention will be required to complete the task. Policies is a representation of how business mapped to the system used for service provisioning. Policies can be used in different level, so it needs a higher -level specification approach to be adopted, possibly associated with a software tool, that supports the generation of lower-level representation. Under the policies, there is abstract policies. Abstract policies provide a formal representation of access control and its behavior. It is declarative, because it does not specify the actual mechanism of the process, it only lay out the rules of the target purpose.
Junhan Hao says
Policy based network management has been widely used in the field of network security management because of its flexibility, ease of use, automation and so on. A policy is a set of constraining rules configured by a network administrator to protect system security. It is found that the network topology is often neglected in the current network security policy model. However, the network topology is an important consideration in policy-based network management, and the change of network topology will make the network management policy also change. At the same time, as the structure of the network becomes more and more complex, the configuration of the policy will inevitably have conflicts. Therefore, almost all policy-based network security models need to detect policy consistency and eliminate conflicts existing in the policy system, otherwise the system will have security vulnerabilities. Current policy conflict detection methods are divided into single point detection and global detection, both of which have defects. If a single point detection is carried out, only the internal policy conflicts of network devices can be detected, but not the policy conflicts among network devices. Global detection, on the other hand, aggregates the rules of all devices for all detection, which may result in conflicting false positives. Because in a large network, it makes perfect sense to have inconsistent policies between different paths.
Jonathan Castelli says
After reading this, it reminded me of what I see daily. In my line of work, I typically deal with firewalls dropping packets or performing stateful packet inspections while we are sending information to and from our application. These firewalls can often replace parts of the packet with different headers. Our application rejects these packets and it stops functioning properly. The firewall team typically has to allow our traffic without the inspection in order to work. They aren’t happy that the firewall can’t do the inspection but eventually they whitelist our IP and Port.
Firewalls can be good and bad for organizations and applications. The firewall teams have to configure the firewalls correctly or they could leave themselves exposed. Finding conflicting policies is essential to making sure the organization stays protected.
Mei X Wang says
Hi Johnathan, I agree with you as well. Firewalls can be helpful in protecting the organization but they also need to be configured properly and additional work such as whitelisting known IPs to be effective. Even on my personal computer, I keep my firewall on but because of how strictly they block outside applications, it’s a process to install “known applications” as well. If the organization is more susceptible to being attacked, having a firewall is definitely great as a buffer for outside threats, there just has to be people in charge making adjustments so they’re not blocking traffic necessary for business needs as well.
Priyanka Ranu says
This chapter focuses on the detection of conflicts in security policies. Separation of duty (SOD) stuck out for me as one of the conflicts. Sensitive combinations of permissions should not be held by the same individual to avoid violating business rules. SOD helps prevent conflict of interest, fraud, etc. For example, individual responsible for HR should not be responsible for designing and implementing security. The chapter mentions about the role-based access control (RBAC) which restricts network access based on a person’s role within an organization. Employees are only allowed to access the information necessary to perform their job. RBAC is quite helpful if the organization has many employees and use third-party contractors as it will help in securing the company’s sensitive data.
Anthony Wong says
Hi Priyanka,
Great points and I agree with your analysis.
I thought the book had a great example of one of the most common SOD’s in just about every company: Accounts Receivable (AR) and Accounts Payable (AP). Essentially, AR is responsible for the money coming into the company for services or products it provided where as AP is responsible for the money coming out of the company for paying bills or services bought. I’m sure an accountant could do both roles, however, the principal of SOD prohibits one person from holding too much power within the business process.
Austin Mecca says
The separation of duty section from this reading was interesting to me as new conflicts arise from a lack of separation. These constraints follow best practices for which sensitive combinations of permissions should not be held by the same individual. The purpose of SoD is to discourage fraud by sprinkling responsibilities and duties for any action or task. By doing this it raises the risk of committing fraud as now it would require more than one individual. SoD is used for more than IT security such as banking and military sectors due to the use of such sensitive and important data. It could be compared to the checks and balances of the government as if it was not in place, one person or group of people would be able to conduct actions without the oversight of others. Role-based access control is adapted to express the constraint because the role hierarchy allows for easy oversight and management of who can do or modify what.
Cami Chen says
Hi, Austin.
I agree with you. Banking and military must have SoD, so people will be not able to take advantage to steal the confidential information that uses in violation of the law. The SoD helps the organization to monitor and restrict the employees’ activities, and this can mitigate the risk of malicious employees committing fraud.
Krish Damany says
When dealing with security policies, there are often conflicts. These conflicts are in two categories: Intra-policy conflicts and Inter-policy conflicts. For both of these conflict types, they can be further organized into Contradictory, Redundant, and Irrelevant conflicts. For contradictory conflicts, these stem from two policies that regard one ruleset that differs. The example in the reading explained this as if an employee was given read and write permissions of a file in one policy, but another policy decides that the employee shouldn’t have these permissions. Redundant conflicts is when one policy supersedes another policy in terms of ranking. This would be if someone had access to a file, but also had access to the root folder the file was contained in. Lastly is the irrelevant conflict, which means that a policy is in place but the conflict cannot occur regardless if the policy was in place or not. An example of this could be if a policy states that one cannot use a well-known port, such as FTP, but the firewall in place already disabled all problematic well-known ports.
Humbert Amiani says
Hi Krish,
It is very common to have contradicting inter-policies especially where privacy meets security so to say. A security policy could suggest monitoring of network traffic while a privacy policy warns of the implications of viewing certain traffic. In such cases, a compromise would seem the best option to ensure both policies are observed in some sense.
Austin Mecca says
I think this categorization of conflicts is a great addition to a security plan. As we know the more detailed you get in your plan the better it is to pinpoint where an issue stems from, so if we apply this same level of thinking to potential conflicts we can slowly minimize the amount of conflicts based on their severity.
Cami Chen says
It is important to have a clear separation of duty to lower the conflicts in security policies. In order to make the authorization safe, the multiple access of sensitive combinations should not be held by the same person. If the same person owns them, the person can extract the information without permission and use this unlimited access to commit fraud. As this article mentions, the multiple access of sensitive combinations should be held by multiple users. They can monitor each other, so one user is not able to set up too low or too high a price for the nominal customer. However, there is only one user who can create and process the purchase order, and the malicious employee can take advantage to counterfeit the transactions and make the financial statement satisfied for the stakeholders. Thus, the company needs to appropriately set up the authorized access base on the job description, so they will not out of control.
Wenyao Ma says
Hi Cami,
Good point. The division of responsibilities can help set constraints and best practices to reduce fraud. For example, the functions of the people we can create and approve purchase orders should be separated. In addition, the change environment should be separated and developers should not be allowed to access the production environment.
Austin Mecca says
I also touched on this being the most important part. The SoD and the fact that you have assigned responsibility for one thing to multiple people, this way there cant be one person who flies under all the radars. This checks and balances type setup helps decrease one of the hardest threats to stop, the insider threat. By mitigating this you can put more trust into your employees to handle this as they are help responsible not only to the company and management but also to their peers.
Anthony Wong says
The conflicts in separation of duties is one of the main points that stuck out to me most. Separation of duties is a type of access control where one or more people are required to complete a specific task. This reduces the chances of fraud and malicious activities due to multiple users being involved, which essentially creates checks and balances. An example of this is deploying code on a server in the cloud. One user should be the developer who creates and maintains the code and another user for building the servers and deploying the code on the box. Additionally, there should be proper sign-offs from management before the process begins to further increase awareness. Based off of the two user’s functions, a role-based access control model can be used to ensure each user has the least amount of privilege needed to perform their daily job functions.
Priyanka Ranu says
Hello Anthony,
Great post!
I mentioned about SOD in my post as well. No one user should be given enough privileges as there are higher changes of misusing the system. For example, an HR shouldn’t have the authority to test the software/program and a QA shouldn’t have the ability to access payroll records. You provided a good example of separating the duties of developers where one should be responsible for creating and maintaining a code while the other developer should be responsible for building the servers and deploying the code. The concept of least privilege should be applied where individuals only have access to the information they need in order to complete their job correctly.
Zhen Li says
The key take way from this articles is the separation of Duty in conflicts in security polices. An important class of constrains is separation of duty(SoD) which make sure the sensitive combinations of permissions should not be held by the same individual, to avoid the violating business rules. The purpose of this constraint is to discourage fraud by spreading the responsibility and authority for an action or task, thereby raising the risk involved in committing a fraudulent act, by requiring the involvement of more than one individual. And SoD has two main categories static SoD and dynamic SoD to balance.
Heather Ergler says
I found this chapter interesting because of the various methods for detecting policy conflicts in firewall configurations and the multidimensional lens that needs to be placed within the same firewall and across the layers of firewalls that make up the firewall architecture. It is interesting how detecting firewall policy conflicts has advanced from manual checks to data queries to more artificial intelligence / machine learning techniques using tools that allow for algorithm building based on the layer the firewall is protecting and the granularity of the policy being examined.
Anthony Messina says
Firewall ACL conflicts was interesting. It discussed the different types of firewalls and what part of the packet they are reading to allow or drop traffic. The basic packet filter firewalls work at the network and transport International Organization of Standardization/Open System Interconnection(ISO/OSI)layer, which makes decisions based on five fields: the Internet Protocol (IP) address and ports of the source and destination, and the IP protocol type. At the highest level of the ISO/OSI stack, there are the application firewalls. Application firewalls are usually tailored to one or more specific protocols to perform a more focused analysis. The most widespread one is the Web Application Firewall, which observes HTTP properties and fields. Theses firewalls can sense specific types of attacks such as brute force login attempts and SQL injections. Because some packets may be allowed on more than one ACL, it is important to stack the ACL’s according to the most important rule being first, as the firewall will allow a packet through on the first rule that it matches. Conflicts can occur on application firewalls if the correct service is not selected in the firewall. For example, if a rule states that any “Untrust” traffic is allowed to any server in the “Web” zone, on port 80 and 443 but no service is selected, then the firewall is not looking for HTTP/S traffic on that rule. It is essentially just a port based rule. No the attacker could send malformed packets with any kind of traffic to port 80/443 and the firewall is none the wiser. I work with application firewalls at work, and I find mis-configured rules all the time that do not specify a service (or type of traffic) to be allowed on the rule. This negates the purpose of the firewall and opens up more security holes.
Krish Damany says
Hi Anthony,
Your post goes to show that the firewalls in which we set up are only as secure as we make them. The assumption that nothing bad will happen if port 80/443 are open because they are a needed and well-known port can be detrimental to the firewall and organization’s system. In addition to port-based rules, another method or two should be implemented to greater mitigate risk.
Prince Patel says
This document highlights the importance and ways to detect and manage conflicts in security policies. This is important especially for both the research and industrial communities. The document’s prime goal was to focus on the detection of conflicts, the executable policies, and the detection of policy conflicts within the computer networks, with greater industrial support output. Support in industrial products can be expected to appear in the near future for security policies in other scenarios and at a variety of abstraction levels. The document also proposed the discussion of Semantic Web technology and how it can be applied to these tasks, offering a strategy that can be successful for the deployment in real systems.
Vanessa Marin says
One of the key take-away’s in this chapter is the criticality of Segregating Duties. (SoD). This is an effective way of creating rules where user A cannot perform conflicting actions within the same process. Using these types of constraints require a good understanding of each business process so that a security designer is able to find inconsistencies in the policy. At times addressing these inconsistencies may require revisions of policy, limiting user roles and responsibilities or modifying the specifics around the constraints to tight or loosen the reigns around it. There are two types of SoDs — static and dynamic. . Static surrounds very specific roles that are very specifically defined as to what each can or cannot do. The dynamic roles consider the timing of the action. where there is a strong reliability on the system to keep ‘precise track of each task”.
Segregation of Duties is a key tool used in the finance industry or in manufacturing where certain transactions require approval from another entity to be processed. They are used primarily to raise the risk that is involved in performing fraudulent transactions, effectively reducing a potential conflict of interest.
Zhen Li says
Hi, Vanessa, I totally agree with your points, I also mentioned the separation duties in my comment. The separation of duty(SoD) could make sure the sensitive combinations of permissions should not be held by the same individual, to avoid the violating business rules in some extent.
Haozhe Lin says
Some of the main gains of this reading include noticing the differences between abstract strategies and executable strategies, and the importance of detecting conflicts in authorization and access mechanisms. The abstract policy attempts to define the required behavior but does not specify a detailed mechanism for forcing the behavior. The executable policy is configured in detail and is directly understood by the system used. There are tools and methods for detecting conflicts. This reading provides a very good and easy-to-understand example to show how the unknown conflict becomes a security problem, as shown in Figure 55.3. User privileges may be restricted, such as policies, which can access certain files in the system, but if they can access other folders or regions containing the same type of files or information, what should they do? This basically means that security policies become useless. We must realize that there are these types of conflicts in our environment. I also discovered how these concepts and materials fit with firewall and the semantic web.
Jonathan Castelli says
I enjoyed your summary once again. It seems that having executable strategies is more valuable than having abstract strategies. Having abstract policies could cause security problems. It’s important for the firewall team to develop executable strategies when creating the rules and separation of duties.
Kyuande Johnson says
A key takeaway from this section is topic of separation of duties. Separation of duties is the concept of having more than one person required to complete a task. In business the separation by sharing of more than one individual in one single task is an internal control intended to prevent fraud and error. Some examples of real life scenarios of separation of duties:” Same person should not be able create a vendor and pay invoices”, Hiring employees and paying salaries and Same person should not prepare bank deposits and verify cash receipts.
A solution to this issue is Role Based Access control. Role Based Access Control is an approach to restricting system access to authorized users. It is used by the majority of enterprises with more than 500 employees. RBAC lets employees have access rights only to the information they need to do their jobs and prevents them from accessing information that doesn’t pertain to them.