Authentication, Authorisation & Accounting Flashcards
What are the key defences managed under “authentication”?
Under Authentication, several key defences are managed to ensure that users or devices are who they claim to be before they are granted access to resources. Some of these defences include:
- Passwords: The most common form of authentication, where users must enter a secret password to verify their identity. Strong password policies help protect against brute force and dictionary attacks.
- Two-Factor Authentication (2FA) / Multi-Factor Authentication (MFA): Requires users to provide two or more verification factors, such as something they know (password), something they have (a security token or smartphone), and something they are (biometrics like fingerprints or facial recognition).
- Biometric Authentication: Uses unique physical characteristics of the user, such as fingerprints, retina scans, or facial recognition, to verify identity. This provides a high level of security, especially when combined with other factors.
- Security Tokens: Physical or virtual devices that generate a unique, time-sensitive code used for authentication. Examples include hardware tokens, SMS codes, or app-based tokens.
- Public Key Infrastructure (PKI): Uses digital certificates and public/private key pairs to authenticate users or devices, ensuring that the communication is secure and the parties involved are legitimate.
- Single Sign-On (SSO): Allows users to authenticate once and gain access to multiple related systems or applications without needing to log in again, improving security and user experience.
- CAPTCHAs: Used to distinguish between human users and automated bots by requiring users to complete tasks that are easy for humans but difficult for bots, preventing automated attacks on login systems.
- Federated Identity Management: Enables users to authenticate across multiple systems or domains using a single identity provider, which is particularly useful in cloud services and collaboration across organisations.
These defences are essential components of a robust authentication strategy, helping to secure access to systems and prevent unauthorised users from gaining entry.
What are the key defences managed under “authorisation”?
Under Authorization, several key defences are managed to ensure that authenticated users only have access to the resources and actions they are permitted to use. Some of these defences include:
- Access Control Lists (ACLs): Define what actions or resources a particular user or group of users is allowed to access. ACLs specify permissions such as read, write, or execute for different resources.
- Role-Based Access Control (RBAC): Assigns permissions to users based on their role within an organisation. Each role has a set of permissions, and users are granted access based on their assigned role, simplifying permission management.
- Mandatory Access Control (MAC): A strict access control method where access to resources is determined by a central authority based on predefined security policies. Users cannot change access rights, which are assigned based on the classification of information and user clearance levels.
- Discretionary Access Control (DAC): Allows the owner of a resource to control who has access to it and what level of access they have. This method is flexible but can be less secure if not properly managed.
- Attribute-Based Access Control (ABAC): Grants access based on attributes (such as user characteristics, resource types, or environmental conditions). ABAC provides a more dynamic and granular approach to access control compared to RBAC or DAC.
- Policy-Based Access Control: Uses high-level policies to govern access to resources. These policies can include conditions like time of day, location, or device type, allowing for more context-aware access decisions.
- Separation of Duties (SoD): Ensures that no single user has control over all aspects of a critical task. This reduces the risk of fraud or error by requiring multiple users to complete different parts of a task.
- Least Privilege Principle: Ensures that users are granted the minimum level of access necessary to perform their job functions. This reduces the risk of misuse or accidental damage by limiting access to only what is essential.
- Privileged Access Management (PAM): Focuses on securing and monitoring the use of privileged accounts, which have elevated access rights. PAM solutions often include features like session monitoring, just-in-time access, and automatic deactivation of elevated permissions.
These defences are crucial in managing and enforcing what authenticated users are allowed to do within a system, ensuring that access is granted appropriately and securely.
What is Mandatory access control (MAC)?
Mandatory Access Control (MAC)is a stringent access control model where the system enforces security policies based on predefined classifications and user clearances. Users, referred to as subjects, cannot alter these rules, and access to resources, known as objects, is strictly controlled.
Key Features of MAC:
- Central Authority: The system centrally manages access rights, not the users.
- No Read Up, No Write Down: Subjects cannot read objects at a higher classification level (“no read up”) or write to objects at a lower classification level (“no write down”).
- High Security: Typically used in high-security environments like military or government systems.
Example:
A subject with “Secret” clearance cannot access a “Top Secret” object and cannot lower its classification. MAC ensures strict and consistent control over access, minimising the risk of unauthorised access or data breaches.
What is discretionary access control (DAC)?
Discretionary Access Control (DAC) is an access control model where the owner or creator of a resource, such as a file or folder, has the authority to determine who can access that resource and what level of access they have. The owner can grant permissions to other users, allowing them to read, write, or execute [r,w,x] the resource based on their discretion.
Key Features of DAC:
- Owner Control: The resource owner has full control over who can access the resource and can modify these permissions at any time.
- Implemented using ACLs: DAC is commonly implemented through Access Control Lists (ACLs), where the owner defines and manages access rights for other users or groups. The ACL specifies who can access the resource and what actions they can perform.
- Flexibility: DAC is flexible and easy to manage, especially in environments where resource owners need to frequently adjust access rights.
- Less Secure: Because users can share access rights, DAC is considered less secure than other models like MAC, as it can lead to unintended access if permissions are not carefully managed.
Example:
In a DAC system, if you create a document, you can decide who else in your organisation can view, edit, or delete that document. You can also change these permissions as needed, giving you full control over access to your resources. However, this flexibility can lead to security risks if permissions are not managed properly.
What is role-based Access control (RBAC)?
Role-Based Access Control (RBAC) is an access control model that assigns permissions to users based on their roles within an organisation. Instead of granting permissions to each user individually, permissions are associated with specific roles, and users are then assigned to these roles based on their job functions.
- Role Assignment: Users are assigned to roles that correspond to their responsibilities within the organisation. For example, a “Manager” role might have different permissions than a “Staff” role.
- Permission Management: Permissions are granted to roles, not directly to users. This simplifies management, as changing a user’s access rights only requires changing their role assignment.
- Separation of Duties: RBAC supports the principle of least privilege by ensuring that users have only the permissions necessary to perform their job functions, reducing the risk of abuse or error.
- Scalability: RBAC is well-suited for large organisations, as it simplifies the process of managing access rights across many users and resources.
In an RBAC system, a user assigned to the “HR” role might have permissions to access employee records, while a user in the “Finance” role might have permissions to access financial data. If someone’s job changes, their access rights can be easily updated by assigning them a different role, rather than manually adjusting permissions for each resource.
What is a reference monitor in context of access control?
A reference monitor in the context of access control is a conceptual framework or component responsible for mediating all access requests between subjects (users or processes) and objects (resources such as files, databases, or devices). It enforces access control policies to ensure that only authorised subjects can access or modify resources according to the security rules in place.
- Complete Mediation: It controls all access to resources, ensuring that every access request is checked against the access control policies.
- Isolation: The reference monitor operates independently and cannot be bypassed or tampered with by any subject.
- Verifiability: It must be possible to verify that the reference monitor correctly enforces the access control policies.
- Minimality: The reference monitor should be as small and simple as possible, reducing the chance of errors or vulnerabilities.
The reference monitor is critical in ensuring that the system adheres to its security policies by deciding whether to grant or deny access based on the rules defined. It typically consists of components like the Policy Decision Point (PDP), Policy Enforcement Point (PEP), and Policy Information Point (PIP), which work together to assess access requests, enforce decisions, and gather necessary contextual information.
In essence, the reference monitor acts as the gatekeeper for system resources, providing a fundamental mechanism for maintaining the security and integrity of an access control system.
What are the components of a typical reference monitor?
A typical reference monitor in access control consists of the following components:
- Policy Decision Point (PDP): Determines whether access should be granted or denied based on predefined security policies.
- Policy Enforcement Point (PEP): Enforces the PDP’s decision by allowing or blocking access to the resource.
- Policy Information Point (PIP): Provides necessary contextual information (such as user attributes or environmental data) to the PDP to support accurate decision-making.
These components work together to ensure that access control is properly enforced, maintaining system security and integrity.
What are the steps in a simplified reference monitor architecture?
- Step 1: A subject makes an access request, which is intercepted by the Policy Enforcement Point (PEP).
- Step 2: The PEP forwards this request to a context handler, which is responsible for determining how any applicable authorisation policies should be used to make an access control decision.
- Step 3: The context handler sends the request to the Policy Decision Point (PDP) (3a), which determines which policies apply (3b) and which associated contextual attribute values are needed to evaluate these policies.
- Steps 4–5: The PDP requests the attribute values from the context handler, which in turn sends a request to the Policy Information Point (PIP) to retrieve the attribute values. The PIP queries the subjects, resources and environment to evaluate the attributes and returns these values via the context handler to the PDP.
- Step 6: The PDP responds to the context handler, based on the evaluation of the authorisation policies. This response includes both the access control decision and any obligations that need to be enforced.
- Step 7: The context handler forwards this response to the PEP, which enforces the access control decision and permits or rejects access to the system resource.
What are the three main types of accountability requirements in the context of IT systems?
Non-Repudiation:
- Ensures that a user cannot deny the authenticity of their actions or communications. This is achieved through mechanisms like digital signatures, which provide verifiable proof that a specific individual performed a particular action, such as sending a message or approving a transaction.
Digital Forensics:
- Involves the collection, preservation, and analysis of electronic data to investigate and respond to security incidents. Digital forensics is crucial for understanding how a breach occurred, identifying the responsible parties, and gathering evidence for legal proceedings or internal reviews.
Compliance:
- Refers to the adherence to laws, regulations, and organisational policies regarding data protection and security. Compliance requirements often mandate regular audits, reporting, and documentation to ensure that the IT systems are following the necessary standards and procedures, thereby maintaining accountability.
How is data collection managed in a typical web application?
In a typical web application, data collection is managed through logging mechanisms that capture various types of information from different components of the system. This logged information is crucial for monitoring, troubleshooting, security, and performance analysis.
Types of Logged Information:
-
User Activity Logs:
- Login Attempts: Records of successful and failed login attempts, including timestamps and user IDs.
- Page Views: Details of which pages were accessed, by whom, and when.
- Actions Performed: Specific actions taken by users, such as form submissions, file uploads, or data modifications.
-
Server Logs:
- HTTP Requests: Logs of incoming HTTP requests, including request method (GET, POST), URL accessed, status codes returned, user agents, and IP addresses.
- Error Logs: Detailed records of any errors encountered by the server, including application errors, failed database queries, and security-related incidents.
- Performance Metrics: Information on server load, response times, memory usage, and other performance-related metrics.
-
Database Logs:
- Query Logs: Records of SQL queries executed, including time taken, affected rows, and any errors encountered.
- Transaction Logs: Details of database transactions, including commit and rollback events.
-
Security Logs:
- Authentication Events: Logs of authentication processes, including successful and failed logins, password changes, and multi-factor authentication (MFA) attempts.
- Access Control Logs: Records of access control decisions, such as granting or denying access to specific resources.
- Intrusion Detection Logs: Logs generated by security tools that detect and report potential security threats, such as unusual login patterns or attempts to access restricted areas.
Components from Which Information is Collected:
- Web Server: Collects HTTP request logs, error logs, and performance metrics. Commonly managed by server software like Apache, Nginx, or IIS.
- Application Server: Logs user activity, application-specific errors, and security events. This component is responsible for executing the business logic of the web application.
- Database Server: Manages query logs and transaction logs. It records all interactions with the database, including data retrieval, insertion, updates, and deletions.
- Security Tools: Collects security-related logs, including those from intrusion detection systems (IDS), firewalls, and authentication services.
These logs are typically stored in centralised log files or logging systems that can be analysed to ensure the web application is functioning correctly, securely, and in compliance with relevant regulations.
What are the considerations involved with log storage and management?
Considerations in Log Storage and Management:
-
Security Benefits of Distributed Log Storage:
- Enhanced Security: Storing logs from different components (e.g., web server, application server, database server) in separate locations can enhance security. If an attacker compromises one system, they may not have access to all logs, reducing the risk of tampering with the entire log set.
- Isolation of Logs: Different storage locations can limit the damage in the event of a breach. For example, if the web server logs are compromised, the database logs stored elsewhere might still be secure, preserving crucial forensic evidence.
-
Challenges of Distributed Log Storage:
- Difficulty in Analysis: When logs are stored in different places, it becomes harder to analyse them comprehensively. To perform effective analysis, logs from various components need to be consolidated, requiring additional steps to gather and merge the logs into a single view.
- Time Synchronisation: For accurate log analysis, especially when investigating incidents or correlating events, it’s essential that all logs have synchronised timestamps. This requires synchronising clocks across all devices that generate logs, which can be challenging in a distributed environment.
-
Retention Policies:
- Storage Duration: Logs should be stored for a sufficient period to allow for historical analysis, compliance audits, and forensic investigations. The retention period should balance the need for data availability with storage costs and privacy regulations.
- Data Protection: Logs often contain sensitive information, so they must be stored securely, with encryption and access controls to prevent unauthorised access.
-
Performance Impact:
- Resource Management: Log storage and management should be designed to minimise the impact on system performance. This includes efficient log rotation, compression, and archiving strategies to ensure that logging does not degrade the performance of the application.
-
Compliance and Legal Considerations:
- Regulatory Requirements: Log management must comply with relevant regulations, such as GDPR, which may dictate how long logs can be stored and how they must be protected.
- Auditability: Logs should be managed in a way that supports auditability, ensuring that they are complete, accurate, and cannot be tampered with.
Summary:
While storing logs in different places can enhance security by isolating them and reducing the risk of tampering, it introduces challenges in log analysis. Consolidating logs for analysis requires additional effort to gather them from different sources and synchronise their timestamps. Effective log management balances these considerations, ensuring security, performance, and compliance.
What are the logging obligations under the GDPR?
Under the GDPR, organisations have several key logging obligations, linked to specific sections of the regulation:
1. Data Minimisation:
- Principle: Only collect and store necessary personal data in logs.
- Relevant Section: Article 5(1)(c) - Data minimisation.
2. Purpose Limitation:
- Principle: Logs must be used solely for their intended purpose, such as security monitoring or compliance.
- Relevant Section: Article 5(1)(b) - Purpose limitation.
3. Data Security:
- Principle: Protect logs containing personal data with appropriate security measures like encryption and access controls.
- Relevant Section: Article 32 - Security of processing.
4. Retention and Deletion:
- Principle: Retain logs only as long as necessary and securely delete or anonymise them when no longer needed.
- Relevant Section: Article 5(1)(e) - Storage limitation.
5. Transparency and Accountability:
- Principle: Maintain clear documentation of logging practices to demonstrate compliance and ensure transparency.
- Relevant Sections: Article 5(1)(a) - Lawfulness, fairness, and transparency; Article 24 - Responsibility of the controller.
6. Data Subject Rights:
- Principle: Ensure logging practices respect individuals’ rights, such as access and deletion requests.
- Relevant Sections: Articles 15-18 - Rights of access, rectification, erasure, and restriction of processing.
7. Incident Response:
- Principle: Use logs to detect, investigate, and respond to data breaches, supporting timely reporting to authorities.
- Relevant Sections: Articles 33-34 - Notification of a personal data breach to the supervisory authority and communication to the data subject.
These sections ensure that logging practices align with GDPR principles, safeguarding personal data and ensuring compliance.