Executable policies are where ‘the rubber meets the road’ in terms of configuring security systems. Executable policies are the prescribed course of action an engineer or system owner needs to follow to ensure a policy is enacted. As discussed in the assigned reading, firewalls are a great example of policy conflicts both in the abstract (high level) and in the executable policies. The propensity for conflicts is because the abstract policy may require specific traffic to be blocked, but in the configuration of that firewall rule, it may lead to legitimate business traffic being denied and inadvertently could impact business operations.
One of the more interesting points that I took away from this reading was different conflict resolution methods for firewalls. A quick summary of the different methods included in the readings would be :
1. Deny overrides: Rules prescribing access denial take precedence.
2. First applicable: Rules are evaluated in order
3. Most specific wins: When one authorization dominates another, the most specific wins.
I imagine that these deny-overrides and first-applicable may work together with the ‘most-specific-wins’ if a specificity is not defined for a relationship, but I am curious about the pros and cons of using one over the other.
Nice summary of the conflict resolution methods, Andrew. I am also curious of how the different methods might be applied and whether or not the compatibility between the first two methods exist. Denying overrides seems more important to occur first, compared to evaluating conflicts in order.
When implementing a security policy, it is common to run into conflicts, contradictions, and other issues that may inhibit the implementation of the policy. There are many different types and categorizations of conflicts, and one major way to distinguish conflicts is whether they are intra-policy conflicts (conflicts that exist within a single policy) or inter-policy conflicts (conflicts that exist in relation to another policy). Each type of conflict can then be further categorized as contradictory, redundant, or irrelevant. Once conflicts can be acknowledged and categorized, having a high-level abstract representation of the policy can help in resolving the issues.
It was interesting from the article’s exposition that the executable policy can be regarded as the configuration of the security enforcement mechanism, and it can be known in the security parlance as security configuration. In that regard, security configuration is fundamentally expressed according to a respective configuration language. I was also impressed about the semantics of this language is finally permitted by the establishment of algorithm that computes the outcome of a configuration at operations time. As a result, configuration authors need to have a mint knowledge of the semantics evaluation, such that they can configure the behavior of the enforcing mechanism exactly according to the policy they want the system to implement. Security configuration taxonomizing a broader collections of positive (respectively, negative) authorization rules and also that provides solutions to resolve the conflicting situations can be included in the evaluation semantics. Hence, the rules that establishes the semantics of the composition of different constructs of the language can be made to handle conflicts by applying a pre determined strategy.
Identifying cybersecurity policy conflicts is one of the most critical components of protecting information systems from external threats and relies on an interim solution that is easy to understand and sufficient to cope with the implementation of some. Firewalls are devices used to separate parts of the network with different levels of security, and firewalls are classified according to their function. The most specific firewall functions are packet filters, which do not maintain state information [distinguishing packets belonging to established Transmission Control Protocol (TCP) connections]. They are also known as stateless firewalls. Firewalls that perform stateful packet inspection are called stateful firewalls.
Stateless firewall uses clues from the destination address, source, and other key clues to decide whether the threats are present, blocked or restricted. The benefits of a stateless firewall does not need to track connection sessions, Additionally, heavy traffic for stateless firewalls are no match which performs well under pressure without getting caught.up in the details.
This chapter talks about the importance of separation of duty. For example, the person inputting or creating a payment in the system should be separate from the person approving them. If these roles are combined then it’s easy to create fake payments in the system and embezzle money.
Ideally, there’d also be some separation between IT and cyber security. They should work together, but often IT is focused on availability while cybersecurity is working on confidentiality and integrity.
I agree with you that IT is usually concerned with availability. Sensitive combinations of permissions should not be held by the same person to avoid violating business rules. The benefit of segregation of duties is to avoid creating fraud as much as possible. The purpose of this constraint is to deter fraud by spreading the responsibility and authority for actions or tasks.
Conflict resolution is a key point I took away from this reading. A large part of my role is to make sure customers understand how to avoid permission conflicts within the system and software. Many times on the OS we will see that users do not own their home directories or they have conflicting group access. In the software my organization makes, if you are denied access to a file or any object, but have been granted access through another group, you will be unable to see the file or object. This “strategy” is also termed deny-override where the denial takes precedence.
I think the fact that your workplace software (not sure if it is what you use or what you sell) uses deny-override conflict resolution is smart. Sometimes administrators forget to remove individuals from previous workgroups, which creates a vulnerability that could potentially be exploited if the employee ever has bad intentions. As mentioned in earlier chapters in the textbook and previous classes, many exploits and data breaches are executed by disgruntled or technologically unaware employees.
This is a very informative write-up. I mainly found very interesting the paragraph on manual testing and how it was simplified into one of two preferred tasks, namely:
Setting up connections to verify whether they succeed and comparing them with the authorization policy
Using software can probe hosts, servers, and devices for open ports and available features.
Secondly, while clearly articulating industry-effective open-source software used for scanning, the paragraph makes mention of the pros (detailed scanning) and cons (time, effort, and further comparison to existing firewall policy even after scanning) of the vulnerability scanning efforts, a subcomponent of manual testing.
Thirdly, the mention of conflicts that could emanate from the absence of separation of duty wherein sensitive combinations of permissions is held by the same individual who could abuse existing business rules. Policies should be based on the maker, not being the checker; the individual who puts in a firewall device access request should not in any way be the one who approves and reviews or approves the request.
This is absolutely fantastic analysis, but tools are needed to support the analysis of the security policies, and a crucial element that signals problems in the policies is represented by the presence of conflicts (contradictions or ambiguities in the policy specification, which may lead to anomalies in the application of the policy. Despite of this, your answer looks great.
One point I took away from this reading is that query-based conflict detection is only as good as the administrators who are in charge of detecting conflicts in security policies. Query-based detection uses a coding language (the one in the textbook is SFQL) to send queries to the firewall prompting answers regarding the policies and rules that are in place. The reading states that administrators often do not know what to query, but this can be mitigated by a Firewall Analyzer that proposes a set of standard queries.
Abstract policies include representation of the access control and their behavior. As an example, if the database is storing a credit card information, then it should not be accessible from the outside of the network. Abstract policy doesn’t include the mechanism used to enforce that policy. It instead identifies the behavior of the services in the initial step. The executable policies specify the access control in such a way that they could be process the access control component. It could be also considered as the security configuration of the system. As it defined it in a way that the system could recognizes it.
Hi Vraj, thanks for your post. This is a great concept to be familiar with, in order to correctly understand the mechanisms a system is using. In my job, the XACML policy language came up during a 3rd party risk management assessment, and it was a critical point of evaluation to determine the access control mechanisms a vendor had in place. Knowing that the vendor did not have an executable policy in operation, my team had to reject the vendor.
I found it particularly interesting that conflicts in network security policies is such a prevalent topic currently; I found query-based conflict detection to be the most interesting solution to this issue. Structured Firewall Query Language, SFQL, was an intriguing concept. The main issue with this method is that the administrators are responsible for writing and understanding queries, when they were said to often be unaware of what exactly they should query.
The conflict of separation of duty (SOD) stood out to me in this reading. Access should be spread to multiple users to avoid risks. As a part of my job, I have to verify what users have authority and if that authority/user is appropriate or not. If a user is not appropriate, this can raise the risk by an individual compromising the company’s reputation. As such, multiple access of sensitive information should not be authorized by one user.
I agree SOD is key in any organization. Providing access to users who may not need it can introduce additional risks. In my role, I tell our customers the best practice is to avoid providing everyone access at initial standup in production. We have a concept of authenticated users who are given limited access and then once roles of all individuals have been determined the admin should start supplying access on a group basis instead of a user basis.
I agree,
Separation of Duties is an essential aspect of access controls.
An employee should only have access to what they need to complete their task. All other access to resources should be restricted. In any case an employee is required to obtain additional access to resources they must go though an approval process to obtain access. Access should be check on a daily basis to ensure every user have the correct permission for their job.
Although policy conflicts are resolved in the evaluation semantics of the security configuration language, inexperienced configuration authors can still introduce errors. Policies that enforce unexpected security attributes can originate from misconfigured security enforcement devices. Errors in program source code can create incorrect runtime behavior, and researchers have been working to identify particularly counterintuitive extremes or variances that may arise from misconfigurations. On the other hand, they have focused more on how to study conflicts in the context of abstract security policies, where the specifics of the mechanisms for implementing policy enforcement are not a part of the model’s usual situation.
One takeaway from this reading was the overview of policy enforcement mechanisms, XACML (eXtensible access control markup language) is one of the many industry best practices which enforce access control policies. XACML is an abstract policy language (meaning it does not declare the specific blueprints/mechanisms to enforce a policy), but is highly configurable with tools that can directly process the language–giving it properties of an executable policy language. Rei and KAoS are also newer examples of executable policy enforcement languages/mechanisms.
The advent of XACML has made it possible to develop various access control policies in different environments flexibly and straightforwardly. The generality of XACML has enabled the standardization of access control policies and processes across systems. XACML is a primarily machine-generated language; it can be used in multiple applications and promote access control interoperability between different systems.
The purpose of Separation of duties 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.
Separation of duties is the foundation of access controls. And example of separation of duties within an organization would be separating the human resources, payroll accounting, and the treasure roles to prevent insider threats and decrease access privileges
Executable policies are where ‘the rubber meets the road’ in terms of configuring security systems. Executable policies are the prescribed course of action an engineer or system owner needs to follow to ensure a policy is enacted. As discussed in the assigned reading, firewalls are a great example of policy conflicts both in the abstract (high level) and in the executable policies. The propensity for conflicts is because the abstract policy may require specific traffic to be blocked, but in the configuration of that firewall rule, it may lead to legitimate business traffic being denied and inadvertently could impact business operations.
One of the more interesting points that I took away from this reading was different conflict resolution methods for firewalls. A quick summary of the different methods included in the readings would be :
1. Deny overrides: Rules prescribing access denial take precedence.
2. First applicable: Rules are evaluated in order
3. Most specific wins: When one authorization dominates another, the most specific wins.
I imagine that these deny-overrides and first-applicable may work together with the ‘most-specific-wins’ if a specificity is not defined for a relationship, but I am curious about the pros and cons of using one over the other.
Nice summary of the conflict resolution methods, Andrew. I am also curious of how the different methods might be applied and whether or not the compatibility between the first two methods exist. Denying overrides seems more important to occur first, compared to evaluating conflicts in order.
When implementing a security policy, it is common to run into conflicts, contradictions, and other issues that may inhibit the implementation of the policy. There are many different types and categorizations of conflicts, and one major way to distinguish conflicts is whether they are intra-policy conflicts (conflicts that exist within a single policy) or inter-policy conflicts (conflicts that exist in relation to another policy). Each type of conflict can then be further categorized as contradictory, redundant, or irrelevant. Once conflicts can be acknowledged and categorized, having a high-level abstract representation of the policy can help in resolving the issues.
It was interesting from the article’s exposition that the executable policy can be regarded as the configuration of the security enforcement mechanism, and it can be known in the security parlance as security configuration. In that regard, security configuration is fundamentally expressed according to a respective configuration language. I was also impressed about the semantics of this language is finally permitted by the establishment of algorithm that computes the outcome of a configuration at operations time. As a result, configuration authors need to have a mint knowledge of the semantics evaluation, such that they can configure the behavior of the enforcing mechanism exactly according to the policy they want the system to implement. Security configuration taxonomizing a broader collections of positive (respectively, negative) authorization rules and also that provides solutions to resolve the conflicting situations can be included in the evaluation semantics. Hence, the rules that establishes the semantics of the composition of different constructs of the language can be made to handle conflicts by applying a pre determined strategy.
Identifying cybersecurity policy conflicts is one of the most critical components of protecting information systems from external threats and relies on an interim solution that is easy to understand and sufficient to cope with the implementation of some. Firewalls are devices used to separate parts of the network with different levels of security, and firewalls are classified according to their function. The most specific firewall functions are packet filters, which do not maintain state information [distinguishing packets belonging to established Transmission Control Protocol (TCP) connections]. They are also known as stateless firewalls. Firewalls that perform stateful packet inspection are called stateful firewalls.
Hi Ziijan,
Stateless firewall uses clues from the destination address, source, and other key clues to decide whether the threats are present, blocked or restricted. The benefits of a stateless firewall does not need to track connection sessions, Additionally, heavy traffic for stateless firewalls are no match which performs well under pressure without getting caught.up in the details.
This chapter talks about the importance of separation of duty. For example, the person inputting or creating a payment in the system should be separate from the person approving them. If these roles are combined then it’s easy to create fake payments in the system and embezzle money.
Ideally, there’d also be some separation between IT and cyber security. They should work together, but often IT is focused on availability while cybersecurity is working on confidentiality and integrity.
Hi Madalyn,
I agree with you that IT is usually concerned with availability. Sensitive combinations of permissions should not be held by the same person to avoid violating business rules. The benefit of segregation of duties is to avoid creating fraud as much as possible. The purpose of this constraint is to deter fraud by spreading the responsibility and authority for actions or tasks.
Conflict resolution is a key point I took away from this reading. A large part of my role is to make sure customers understand how to avoid permission conflicts within the system and software. Many times on the OS we will see that users do not own their home directories or they have conflicting group access. In the software my organization makes, if you are denied access to a file or any object, but have been granted access through another group, you will be unable to see the file or object. This “strategy” is also termed deny-override where the denial takes precedence.
Hi Dhaval,
I think the fact that your workplace software (not sure if it is what you use or what you sell) uses deny-override conflict resolution is smart. Sometimes administrators forget to remove individuals from previous workgroups, which creates a vulnerability that could potentially be exploited if the employee ever has bad intentions. As mentioned in earlier chapters in the textbook and previous classes, many exploits and data breaches are executed by disgruntled or technologically unaware employees.
-Mike
This is a very informative write-up. I mainly found very interesting the paragraph on manual testing and how it was simplified into one of two preferred tasks, namely:
Setting up connections to verify whether they succeed and comparing them with the authorization policy
Using software can probe hosts, servers, and devices for open ports and available features.
Secondly, while clearly articulating industry-effective open-source software used for scanning, the paragraph makes mention of the pros (detailed scanning) and cons (time, effort, and further comparison to existing firewall policy even after scanning) of the vulnerability scanning efforts, a subcomponent of manual testing.
Thirdly, the mention of conflicts that could emanate from the absence of separation of duty wherein sensitive combinations of permissions is held by the same individual who could abuse existing business rules. Policies should be based on the maker, not being the checker; the individual who puts in a firewall device access request should not in any way be the one who approves and reviews or approves the request.
This is absolutely fantastic analysis, but tools are needed to support the analysis of the security policies, and a crucial element that signals problems in the policies is represented by the presence of conflicts (contradictions or ambiguities in the policy specification, which may lead to anomalies in the application of the policy. Despite of this, your answer looks great.
One point I took away from this reading is that query-based conflict detection is only as good as the administrators who are in charge of detecting conflicts in security policies. Query-based detection uses a coding language (the one in the textbook is SFQL) to send queries to the firewall prompting answers regarding the policies and rules that are in place. The reading states that administrators often do not know what to query, but this can be mitigated by a Firewall Analyzer that proposes a set of standard queries.
Abstract policies include representation of the access control and their behavior. As an example, if the database is storing a credit card information, then it should not be accessible from the outside of the network. Abstract policy doesn’t include the mechanism used to enforce that policy. It instead identifies the behavior of the services in the initial step. The executable policies specify the access control in such a way that they could be process the access control component. It could be also considered as the security configuration of the system. As it defined it in a way that the system could recognizes it.
Hi Vraj, thanks for your post. This is a great concept to be familiar with, in order to correctly understand the mechanisms a system is using. In my job, the XACML policy language came up during a 3rd party risk management assessment, and it was a critical point of evaluation to determine the access control mechanisms a vendor had in place. Knowing that the vendor did not have an executable policy in operation, my team had to reject the vendor.
I found it particularly interesting that conflicts in network security policies is such a prevalent topic currently; I found query-based conflict detection to be the most interesting solution to this issue. Structured Firewall Query Language, SFQL, was an intriguing concept. The main issue with this method is that the administrators are responsible for writing and understanding queries, when they were said to often be unaware of what exactly they should query.
The conflict of separation of duty (SOD) stood out to me in this reading. Access should be spread to multiple users to avoid risks. As a part of my job, I have to verify what users have authority and if that authority/user is appropriate or not. If a user is not appropriate, this can raise the risk by an individual compromising the company’s reputation. As such, multiple access of sensitive information should not be authorized by one user.
Hi Victoria,
I agree SOD is key in any organization. Providing access to users who may not need it can introduce additional risks. In my role, I tell our customers the best practice is to avoid providing everyone access at initial standup in production. We have a concept of authenticated users who are given limited access and then once roles of all individuals have been determined the admin should start supplying access on a group basis instead of a user basis.
Great Points Victori,
I agree,
Separation of Duties is an essential aspect of access controls.
An employee should only have access to what they need to complete their task. All other access to resources should be restricted. In any case an employee is required to obtain additional access to resources they must go though an approval process to obtain access. Access should be check on a daily basis to ensure every user have the correct permission for their job.
Although policy conflicts are resolved in the evaluation semantics of the security configuration language, inexperienced configuration authors can still introduce errors. Policies that enforce unexpected security attributes can originate from misconfigured security enforcement devices. Errors in program source code can create incorrect runtime behavior, and researchers have been working to identify particularly counterintuitive extremes or variances that may arise from misconfigurations. On the other hand, they have focused more on how to study conflicts in the context of abstract security policies, where the specifics of the mechanisms for implementing policy enforcement are not a part of the model’s usual situation.
One takeaway from this reading was the overview of policy enforcement mechanisms, XACML (eXtensible access control markup language) is one of the many industry best practices which enforce access control policies. XACML is an abstract policy language (meaning it does not declare the specific blueprints/mechanisms to enforce a policy), but is highly configurable with tools that can directly process the language–giving it properties of an executable policy language. Rei and KAoS are also newer examples of executable policy enforcement languages/mechanisms.
The advent of XACML has made it possible to develop various access control policies in different environments flexibly and straightforwardly. The generality of XACML has enabled the standardization of access control policies and processes across systems. XACML is a primarily machine-generated language; it can be used in multiple applications and promote access control interoperability between different systems.
The purpose of Separation of duties 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.
Separation of duties is the foundation of access controls. And example of separation of duties within an organization would be separating the human resources, payroll accounting, and the treasure roles to prevent insider threats and decrease access privileges