From your personal experience: Which risks are involved in electronic payment systems?
Start with thinking about the vulnerabilities of today’s methods, procedures, and mechanisms you are familiar with. Here are two possible scenarios:
\begin{parts}
\part Paying with a debit card (e.g. EC Maestro): starting with its use in a shop and ending with the money withdrawal from your bank account.
\part Home banking using a static (e.g. snail-mailed) or dynamically generated transaction authentication number (TAN), e.g. sent from your bank via SMS (mTAN) or using a smartphone app (pushTAN).
\end{parts}
What are the advantages of smart cards (such as your thoska), carrying a microprocessor for cryptographic computations?
Electronic payment involves theft of data or money. Hackers may get access to bank accounts and use it the same way as the normal user but with different intentions (get rich). To prevent hacking of accounts, banks use different ways of defense.
While paying with a debit card, the user must provide the card (physical item) and the pin code (knowledge). To prevent bruteforce attacks, a bank account is locked after a short number of invalid pin codes.
Home banking uses a password (knowledge) and a TAN via Mail/Phone to have the possibility of hackers minimized.
Which vulnerabilities are exploited by a buffer overflow attack? How can you counter buffer overflow attacks? How could you at least mitigate the effects of successful buffer overflow attacks?
Buffer overflow attacks aim to trick the softwar to execute futher attack code and exploit whatever the hacker needs. To prevent buffer overflow, one must check the maximum possible length of the input versus the users input. To mitigate any successfull attack, a programm should be contained and not have access to further information or programms but the necessary.
Similar to HRU, an NI model is basically formalized through a deterministic automaton. Can we also use it to analyze HRU Safety (no matter if by proof or by simulation)?
If yes: How would HRU Safety for NI be defined (in prose)? If no: What extension of the NI model in the lecture would be required to enable Safety analysis?
With an NI model you can proof if it is NI-secure but not HRU safety as the NI Model holds no subjects or objects but domains and states. It must be extended with sets of subjects and objects to do so.
The Bell-LaPadula Model is a model engineered from know abstractions. The lattice that maps subjects and objects is needed to model confidentiality hierarchy (public or confidential subject and objects). The ACM next to that stores the read and write access of subjects and objects.
Both can be used alone to check confidentiality and the ACM can be used to analyze the ACF of the model.
DAC: Individual users specify access rules to objects within their area of responsibility ("at their discretion"). E.g. locally within a project, team members individually define permissions w. r. t. documents (implemented in project management software and workstation OSs) inside this closed scope. With DAC it can happen to loose confidentiality and it's weaker to social engineering attacks.
MAC: System designers and administrators specify system-wide rules, that apply for all users and cannot be sidestepped. E.g. globally for the organization, such that e. g. only documents approved for release by organizational policy rules (implemented in servers and their communication middleware) may be accessed from outside a project’s scope.
All Subjects can also act as objects and can be used to model delegation of rights. Each objects has a type from a type set trough a mapping style.
An HRU model is a special case of a TAM model $T=\{tSubject,tObject\}$ with $\forall s\in S:type(s)=tSubject; \forall o\in O\backslash S:type(o)=tObject$
AC model, similar expressiveness to HRU that can be directly mapped to implementations of an ACM: OS ACLs, DB permission assignment tables. Better suited for safety analyses: precisely statemodel properties for decidable safety.
As with any AC model, the formal components of RBAC are designed to enable access control decisions. However, in the ACF definition of RBAC0 (which is the basis for ACFs of the other RBAC96 models), the component UA is not included. Why?
IBAC is the fundamental model and provides basic expressiveness. The abstraction is very low and not application oriented. No indirection between subjects and objects, Subjects and Objects have direct rights assigned to each other.
RBAC: indirection via roles assigned to subjects
ABAC: indirection via arbitrary attributes assigned to subjects or objects. More scalable and manageable.
We can narrow down the complexity of an HRU model to make it decidable and check, if the model instantiation itself is safe. E.g. a mono-operational model is not useful but expressive and is efficient to analyse and design.
Another way may be heuristic analysis to have heuristics guided safety decisions.
How do we model a read operation, such as for a Unix-OS file system, in HRU? Remember that this operation neither modifies the subject set, nor the object set, nor the ACM.
An Access Control Matrix is a well-structured store to efficiently evaluate and completly analyze an Access Control Function. It only models a single state and cannot predict future proliferation of rights.
The Harrison-Ruzzo-Ulman Model uses the single protection state of an Access Control System and deterministic automata to model runtime changes of these protection states. Formally it uses a State Transition Scheme with given primitives.
The result of the automaton (if its safe or not) is not resulting in an output function but the state space q' of Q in comparison to q (inital state; $safe(q_0,r)$)
Brewer-Nash: no information flow between competing objects. Competing objects belong to the same class. With the history relation, subjects can access new objects only if they didn't access competing objects before.
Least-Restrictive: includes time as a model abstraction. no conflicting information is accumulated in the subject/object potentially increases the amount of information in the subject/object
MLS: labels entities. Class of an entity (subject or object) reflects information it carries and is reclassified whenever an data object is read.