Blog

Categories:

22. 12. 2024

Security Cryptography

Access Permission Control

AAA, i.e. authentication (authentication), authorization (authorization allocation) and accounting (may better billing of provided services). Cryptography is mainly devoted to authentication, but provides information for authorization. For some authentication algorithms, it is difficult to distinguish the authentication and authorization parts, because one server authenticates identity and can further provide information about authorization.

Information Access Control

Cryptography ensures the protection of stored or transported data, its integrity, authenticity and non-repudiation. It can be a powerful tool even in authentication. But it does not address authorization, i.e. the granting of access permissions. It can only support authorization with another layer of protection mechanisms, be it refusal of access (negation of availability in case of password ignorance), anonymization of data or anonymized processing, processing of encrypted data … other examples could be found. But authorization control is a bit of a separate discipline.
The first formalizations of authorization control originated in "computer antiquity." Today we use the descendants of these technologies, but we do not always use them correctly. Therefore, it is advisable to mention the pros and cons of these technologies, including examples where they fail. At the same time, it is a kind of refresh of basic knowledge on this topic.

MAC (Mandatory Access Control)

This abbreviation often evokes to me the integrity control (one of the abbreviations is also MAC), so it is necessary to know the context of the use. The actual access control uses a system of labels, i.e. security labels for each source or individual. Such labels should consist of two parts, classification and affiliation. The classification of data determines the access restriction, i.e. how sensitive the data is. The equivalent for the user is a screening, i.e. for how sensitive the data can get access. Affiliation then indicates for users or data the use method (range restriction). The data can belong to a specific project, group or department, users can be classified into similar limits. Access is granted in this case only and only if the following conditions are met:
- User and data have the same level of classification
- User and data have the same affiliation
Based on the above restrictive procedure, the place of origin is evident, i.e. the intelligence and military community. Nevertheless, it is advisable to protect some data in a similarly restrictive way, on the other hand, this procedure has its obvious advantages and disadvantages. Among the advantages is enforceability, i.e. the rules cannot be changed. Another advantage is compartmentalization, i.e. limited exposure of each resource to only a limited group, this limitation can be significantly more accurate than for hierarchical inheritance of rights.
However, such a solution has its disadvantages. The first is a limitation of communication and cooperation, which can be counterproductive, especially for dynamic collectives. If intensive cooperation between different departments is required, this approach may require extra effort. Furthermore, the creation and maintenance of labels is usually managed by a specialized organizational structure. This must in principle have significantly higher permissions, as it has to manage the data.

DAC (Discretionary Access Control)

The access control is based on ACLs (Access Control List), i.e. permission lists. These are set by the owner of the resource, which can be the system administrator (of the resources) or the author. The above tables pair the permissions to the resources for individual users or user resources. The advantage of this approach is the extreme simplicity of the setup and reaction speed of the system (the owner can set the permissions for the data provided by him). The disadvantage is the need to browse a large number of records, where some of them may or may not have access rights. Subsequently, the question is how these collisions will be evaluated. Another disadvantage is the difficulty of identifying access permissions to individual resources. Nevertheless, this is one of the most commonly used access control systems.

RBAC (Role-based Access Control)

This is the management of permissions based on roles, in other words, on the work, position or role performed, or on the membership of a particular group of users. This is a popular way to implement the principle of least-needed permissions. Deployment needs adequate analysis of the approaches needed for individual positions and determination of the permissions for access to individual sets of data.
The advantage is extreme flexibility. This flexibility means the possibility of assigning users to multiple roles, exploiting the inheritance of permissions within the hierarchy, defining relationships between roles, easy maintenance, centralized policies, and limiting possible conflicts of permissions. The disadvantage, on the other hand, is the need for relationship and obligation analysis. Assigning a large number of overlapping roles to a user can become a problem, which can also lead to omissions when limiting access permissions for a given user. Depending on the extent, it may then be necessary to balance the granularity of access control against the overall complexity of administration.
Beyond the above basic methods, procedures derived from these three basic methods are also used. The rough approximation is as follows:

Context-based access control (CBAC)

This method is usually used on firewalls, where it controls the approval or refusal of access based on the properties of the communication. In a simpler case, it is solved whether the communication protocol is approved or disapproved. More complex systems can only analyse and approve this communication protocol if it corresponds to a standard form of communication (if the context is correct).

Graph-based access control (GBAC)

This is a little-known method that is only used in a limited group of products. When setting permissions, a company hierarchy is created, along with a graph of dependencies and permissions between users. Based on this data, it is then possible to query the system whether the user can obtain permissions to access the given resources.

Lattice-based access control (LBAC)

This approach is based on the creation of a matrix of permissions and their interactions, i.e. relationships between individual objects. These relationships then allow the necessary permissions to be defined. This is a good procedure for situations where specific independent task groups are created in the standard structure of the organization, e.g. for projects. This is a system that has a similar approach to MAC to some extent, may have merit in some cases, but it is an extremely complex approach.

Organisation-based access control (OrBAC)

The organizational scheme extends the original RBAC to some extent and combines it with GBAC. All relationships are thus based on the hierarchical structure of the organization.

Relationship-based access control (ReBAC)

A policy based on user-document relationships requires defining this relationship, e.g. the user is the author of the document, working on the project described in this project and so on. To some extent it is possible to liken this relationship to MAC, where the label is replaced by a relationship.

Rule-set-based access control (RSBAC)

This model is based on the evaluation of certain rules and is very similar to e.g. the permission structure within SeLINUX. The advantage of such a model is the ability to influence the allocation of permissions in case of conflicts of different rights allocations. While such a model is flexible, it requires considerable effort for implementation.

ABAC/PBAC/CBAC (Attribute Based Access Control, Policy Based Access Control or Claim Based Access Control)

These are authorization management systems, based on the definition of data attributes and policies. Policies provide access based on evaluating the rules above the attributes. Because both rules and attributes can provide complex options, it is possible to design very complex access control methods thanks to these technologies. With large-scale settings, it is necessary to use some descriptive scheme that allows easier control methods. Perhaps the best-known method mentioned is a descriptive scheme called XACML.

XACML (eXtensible Access Control Markup Language)

This is an attribute evaluation system described in XML format. The actual writing of the rules uses the properties of the Alpha language (Axiomatic Language for Authorization). Currently, manufacturers are trying to use the definition of authorization on web portals and cloud storage using XACML. Its equivalent is another similar system called NGAC, the principles are practically identical.

Weakness of implementation

There are other methods that should be described, but the possibility of using them is always limited in some way. The general problem with all these systems is weaknesses in the management of information protection under marginal conditions, but these can be a stumbling block for the management system. The biggest complications can be summed up in the following points:

- Creation of information
The problem arises from the creation of this information on the basis of the knowledge and experience base of specific persons, who do not have to pass through the access control network, i.e. do not have the appropriate permissions. Thus, either the permissions are granted to them or refused, even with an impact on the whole principle of data access control. An example is the familiarization of the person with data at a higher level of classification or outside of their permissions, this can affect the protection of a particular project.

- Allocation of permissions
Allocation of permissions may require access to data and its classification by an independent group of persons. At this point, there is a risk that they may become acquainted with data that is outside their clearance or authority. If it is not an independent group of persons but the owner of the data, the level of permission setting depends mainly on the knowledge and experience of that person.

- Chained allocation of permissions
The problem of chained allocation of permissions is not only the case when using one, but also when using a combination of several methods of access control. As an example, it is possible to use a situation that occurs relatively frequently. Data can be stored and processed by one system. The outputs of this system go to the other, usually with a different classification of the data or only the processed data are classified differently. Moreover, often in the second system, data from the first system can be combined with other sources. The resulting problem arises from several reasons. Either the data classification information is lost during the processing, or the data is not reclassified, or, together with a combination of other inputs, it is possible to obtain data with the same or higher classification than the original data. As a result, a user who does not have access to the data in the first system can obtain significantly more valuable data in the second.

- Permissions collision
This is a problem of collisions of two or more source access permissions, where each of the permissions provided provides different values of the permissions for the user. The resulting state then complicates the evaluation and it is difficult to determine which of these values take precedence. Fortunately, this is usually a method of access control, where by default all rights are limited and only some permissions are allowed, yet it is necessary to be careful of the situations mentioned.

- Data science / de-anonymization of data
The user can access data with low classification, but by combination with other data he can restore the original data with higher classification or data to which he does not have access. This is a variant of a problem similar to the concatenated allocation of permissions. As in the previous case, the solution is the use of data curators and anonymization of outputs in a way that makes it difficult or impossible for the user concerned to extract them (online models, not a passive model anonymizing data). Although this is a simple description, solving such a problem is extremely challenging. It often means understanding the context of the situation and the data, and thus getting acquainted with their content.

- Data copy
The user (or the application under the user's rights) or the administrator can create copies of the data, but this data does not have to carry information about the permissions allocated, or the data owner may lose the database of access permissions. This leads to two situations where, in the first case, any person can access this data, in the second case, none. The first example occurs in the case of insider threat, data exfiltration, but also inappropriate backup methods, the second can occur, for example, in the case of ransomware attack.

Conclusion

In the case of system selection, it is necessary to know the possibilities in the field of authentication mechanisms selection, for which it is necessary to consider the possibilities in the field of user permissions management. These mechanisms have their limitations, so it is necessary to think about how to allocate permissions. The alternative is to switch to technologies that will allocate authorisations in the desired way. Of course, it is impossible to forget the protection of information by access control rules throughout its life cycle, the classification of this information is then "only" another dimension.

References:

TSEC - Trusted Computer System Evaluation Criteria (Orange Book)
Source: https://www.nist.gov/
BiBa - Integrity Consideration for Secure Computer Systems
Source: https://www.ucdavis.edu/
BellLaPadula - Secure Computer Systems: Mathematical Foundations
Source: http://www.albany.edu/
NIST - The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments
Source: http://www.nist.gov/
NIST Role Based Access Control
Source: http://www.nist.gov/
NIST Atribute Based Access Control (ABAC) Definition and Considerations
Source: http://www.nist.gov/
OASIS eXtensible Access Control Markup Language (XACML) Version 3.0
Source: http://www.oasis-open.org/

Autor článku:

Jan Dušátko

Jan Dušátko has been working with computers and computer security for almost a quarter of a century. In the field of cryptography, he has cooperated with leading experts such as Vlastimil Klíma or Tomáš Rosa. Currently he works as a security consultant, his main focus is on topics related to cryptography, security, e-mail communication and Linux systems.

1. Introductory Provisions

1.1. These General Terms and Conditions are, unless otherwise agreed in writing in the contract, an integral part of all contracts relating to training organised or provided by the trainer, Jan Dušátko, IČ 434 797 66, DIČ 7208253041, with location Pod Harfou 938/58, Praha 9 (next as a „lector“).
1.2. The contracting parties in the general terms and conditions are meant to be the trainer and the ordering party, where the ordering party may also be the mediator of the contractual relationship.
1.3. Issues that are not regulated by these terms and conditions are dealt with according to the Czech Civil Code, i.e. Act No.89/2012 Coll.
1.4. All potential disputes will be resolved according to the law of the Czech Republic.

2. Creation of a contract by signing up for a course

2.1. Application means unilateral action of the client addressed to the trainer through a data box with identification euxesuf, e-mailu with address register@cryptosession.cz or register@cryptosession.info, internet pages cryptosession.cz, cryptosession.info or contact phone +420 602 427 840.
2.2. By submitting the application, the Client agrees with these General Terms and Conditions and declares that he has become acquainted with them.
2.3. The application is deemed to have been received at the time of confirmation (within 2 working days by default) by the trainer or intermediary. This confirmation is sent to the data box or to the contact e-mail.
2.4. The standard time for registration is no later than 14 working days before the educational event, unless otherwise stated. In the case of a natural non-business person, the order must be at least 28 working days before the educational event.
2.5. More than one participant can be registered for one application.
2.6. If there are more than 10 participants from one Client, it is possible to arrange for training at the place of residence of the intermediary or the Client.
2.7. Applications are received and processed in the order in which they have been received by the Provider. The Provider immediately informs the Client of all facts. These are the filling of capacity, too low number of participants, or any other serious reason, such as a lecturer's illness or force majeure. In this case, the Client will be offered a new term or participation in another educational event. In the event that the ordering party does not agree to move or participate in another educational event offered, the provider will refund the participation fee. The lack of participants is notified to the ordering party at least 14 days before the start of the planned term.
2.8. The contract between the provider and the ordering party arises by sending a confirmation from the provider to the ordering party.
2.9. The contract may be changed or cancelled only if the legal prerequisites are met and only in writing.

3. Termination of the contract by cancellation of the application

3.1. The application may be cancelled by the ordering party via e-mail or via a data mailbox.
3.2. The customer has the right to cancel his or her application for the course 14 days before the course takes place without any fees. If the period is shorter, the subsequent change takes place. In the interval of 7-13 days, an administrative fee of 10% is charged, cancellation of participation in a shorter interval than 7 days then a fee of 25%. In case of cancellation of the application or order by the customer, the possibility of the customer's participation in an alternative period without any additional fee is offered. The right to cancel the application expires with the implementation of the ordered training.
3.3. In case of cancellation of the application by the trainer, the ordering party is entitled to a full refund for the unrealized action.
3.4. The ordering party has the right to request an alternative date or an alternative training. In such case, the ordering party will be informed about all open courses. The alternative date cannot be enforced or enforced, it depends on the current availability of the course. If the alternative training is for a lower price, the ordering party will pay the difference. If the alternative training is for a lower price, the trainer will return the difference in the training prices to the ordering party.

4. Price and payment terms

4.1. By sending the application, the ordering party accepts the contract price (hereinafter referred to as the participation fee) indicated for the course.
4.2. In case of multiple participants registered with one application, a discount is possible.
4.3. The participation fee must be paid into the bank account of the company held with the company Komerční banka č. 78-7768770207/0100, IBAN:CZ5301000000787768770207, BIC:KOMBCZPPXXX. When making the payment, a variable symbol must be provided, which is indicated on the invoice sent to the client by the trainer.
4.4. The participation fee includes the provider's costs, including the training materials. The provider is a VAT payer.
4.5. The client is obliged to pay the participation fee within 14 working days of receipt of the invoice, unless otherwise stated by a separate contract.
4.6. If the person enrolled does not attend the training and no other agreement has been made, his or her absence is considered a cancellation application at an interval of less than 7 days, i.e. the trainer is entitled to a reward of 25% of the course price. The overpayment is returned within 14 days to the sender's payment account from which the funds were sent. Payment to another account number is not possible.
4.7. An invoice will be issued by the trainer no later than 5 working days from the beginning of the training, which will be sent by e-mail or data box as agreed.

5. Training conditions

5.1. The trainer is obliged to inform the client 14 days in advance of the location and time of the training, including the start and end dates of the daily programme.
5.2. If the client is not a student of the course, he is obliged to ensure the distribution of this information to the end participants. The trainer is not responsible for failure to comply with these terms and conditions.
5.2. By default, the training takes place from 9 a.m. to 5 p.m. at a predetermined location.
5.3. The trainer can be available from 8 a.m. to 9 a.m. and then from 17 a.m. to 6 p.m. for questions from the participants, according to the current terms and conditions.
5.4. At the end of the training, the certificate of absorption is handed over to the end users.
5.5. At the end of the training, the end users evaluate the trainer's approach and are asked to comment on the evaluation of his presentation, the manner of presentation and the significance of the information provided.

6. Complaints

6.1. If the participant is grossly dissatisfied with the course, the trainer is informed of this information.
6.2. The reasons for dissatisfaction are recorded in the minutes in two copies on the same day. One is handed over to the client and one is held by the trainer.
6.3. A statement on the complaint will be submitted by e-mail within two weeks. A solution will then be agreed within one week.
6.4. The customer's dissatisfaction may be a reason for discontinuing further cooperation, or financial compensation up to the price of the training, after deduction of costs.

7. Copyright of the provided materials

7.1. The training materials provided by the trainer in the course of the training meet the characteristics of a copyrighted work in accordance with Czech Act No 121/2000 Coll.
7.2. None of the training materials or any part thereof may be further processed, reproduced, distributed or used for further presentations or training in any way without the prior written consent of the trainer.

8. Liability

8.1. The trainer does not assume responsibility for any shortcomings in the services of any third party that he uses in the training.
8.2. The trainer does not assume responsibility for injuries, damages and losses incurred by the participants in the training events or caused by the participants. Such costs, caused by the above circumstances, shall be borne exclusively by the participant in the training event.

9. Validity of the Terms

9.1 These General Terms and Conditions shall be valid and effective from 1 October 2024.