Threat modeling aims at studying the potential problems and attacks against a system in order to document how attacks are mitigated. In this document, we will analyze threats and suggest solutions in order to produce internal threat analysis document. It provides an assessment on how threats are mitigated and which threats are remaining. It only provides the threat model of components developed in this research project. TAS3 is an integration project with the vision of implementing an architecture. Such an architecture-driven approach means to use a methodology where the assessment can be done by component.
The document contains a brief overview of some existing methods, the description of the methodology adopted (derived from the NIST800-30 Microsoft methodology) and the risk assessment by components.
In the deliverable D2.1, the TAS3 Architecture has already presented some inputs in this direction (Annex B that summarizes the threats that the TAS3 architecture is designed to protect against).
Introduction
This section provides a brief overview over some of the existing methods and standards related to risk analysis. It concludes by identifying some issues that to little degree are covered by the current state of the art. Most of the existing methods have been presented in [1Enisa10].
2.1. Risk Analysis Methods
2.1.1. OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation)
OCTAVE [Alberts01] is a general approach for evaluating and managing information security risks. As information security includes issues related to both business and technology, an inter-disciplinary analysis team that includes people from both the business units and the IT department performs the evaluation. The evaluation is performed in three phases:
Build Asset-Based Threat Profiles. The analysis team identifies what is important to the organization, i.e. what are the information-related assets of the organization, and reviews what is currently being done to protect those assets. The analysis team also selects the critical assets that are most important to the organization. The team then describes security requirements for the critical assets and identifies threats to the critical assets.
Identify Infrastructure Vulnerabilities. The team evaluates the information in-frastructure and identifies key information technology systems and components re-lated to each critical asset. Key components are examined for weaknesses (technol-ogy vulnerabilities) that can lead to unauthorized action against critical assets.
Develop Security Strategy and Plans. The analysis team identifies risks to the organization's critical assets and decides what to do about them. The team cre-ates a protection strategy for the organization and mitigation plans to address the risks to the critical assets, based upon an analysis of the information gathered.
OCTAVE provides a snapshot analysis at a given point in time. Therefore, OCTAVE advises that the organization either performs new evaluations periodically or triggered by major events, such as corporate reorganization or redesign of the computing infrastructure. OCTAVE comes with predefined templates for documenting information during the analysis.
2.1.2. CRAMM
CRAMM (CCTA Risk Analysis and Management Method [Siemens10]) provides a stepwise and disciplined risk analysis method that takes both technical and non-technical (e.g. physical and human) aspects of security into account. In its original form, it was adopted as a standard by the U.K. government organization CCTA (Central Computer and Telecommunications Agency). Similarly to OCTAVE, CRAMM defines three stages of analysis:
Asset identification and valuation. The reviewer identifies the physical (e.g. IT hardware), software (e.g. application packages), data (e.g. the information held on the IT system) and location assets that make up the information system. Value is assigned to assets.
Threat and vulnerability assessment. The likelihood of potential problems are identified, taking into consideration both accidental and deliberate threats, such as hacking, viruses, equipment or software failure, wilful damage or terrorism, and errors made by people. Based on this, the risk level is calculated.
Countermeasure selection and recommendation. The measure of risk is evaluated in order to decide what countermeasures should be implemented. CRAMM provides a countermeasure library where a threshold level is associated with the countermeasures, thereby providing aid in the decision whether to implement a given countermeasure.
During a CRAMM analysis, the reviewer gathers information by interviewing the asset owners, system users, technical support staff and security manager. A standardized CRAMM format is used for documenting results, mostly in the form of specialized tables.
2.1.3. Microsoft's Security Risk Management
Microsoft has developed their own risk guideline [Microsoft06]. This guideline defines the Microsoft Security Risk Management Process, which has four primary phases:
Assessing risk. Data are gathered in order to identify risks to the business, and to prioritize between the risks.
Conducting decision support. Functional requirements to mitigate risks are defined. Control solutions (treatments) are identified and evaluated, and a cost-benefit analysis is performed.
Implementing controls. The chosen control solutions are implemented and deployed.
Measuring program effectiveness. The risk management process is analyzed for effectiveness, and an evaluation of whether the controls provide the expected degree of protection is performed.
As risk management is viewed as an ongoing process, these phases constitutes the parts of a risk management cycle. The guideline also goes further than defining this cycle. For example, it provides lists of common assets, threats and vulnerabilities. However, these are not intended to be comprehensive, and analysts are encouraged to add or delete items as necessary.
For example, the risk management guide for IT systems (NIST800-30) [NIST-SP800-30]. defines a methodology to assess risks while developing an application.
2.1.4. CORAS
CORAS [BraberEA07] is a method for conducting security risk analysis. CORAS provides a customized graphical language for threat and risk modelling, and comes with de-tailed guidelines explaining how the language should be used to capture and model relevant information during the various stages of the security analysis. In this respect CORAS is model-based. Special CORAS diagrams are used for documenting intermediate results, and for presenting the overall conclusions. The CORAS language is supported by a structured semantics translating CORAS diagrams into natural language (English) sentences [DahlEA07]. Following the CORAS method, a security risk analysis is conducted in seven steps:
The first step involves an introductory meeting. The main item on the agenda for this meeting is to get the representatives of the client to present their overall goals of the analysis and the target they wish to have analyzed. Hence, during the initial step the analysts will gather information based on the client's presentations and discussions.
The second step also involves a separate meeting with representatives of the client. However, this time the analysts will present their understanding of what they learned at the first meeting and from studying documentation that has been made available to them by the client. The second step also involves a rough, high-level security analysis. During this analysis the first threats, vulnerabilities, threat scenarios and unwanted incidents are identified. They will be used to help with directing and scoping the more detailed analysis still to come.
The third step involves a more refined description of the target to be analysed, and also all assumptions and other preconditions being made. Step three is terminated once all this documentation has been approved by the client.
This step is organised as a workshop, drawn from people with expertise on the target of the analysis. The goal is to identify as many potential unwanted incidents as possible, as well as threats, vulnerabilities and threat scenarios.
The fifth step is also organised as a workshop. This time the focus is on estimating consequences and likelihood values for each of the identified unwanted inci-dents.
This step involves giving the client the first overall risk picture. This will typically trigger some adjustments and corrections.
The last step is devoted to treatment identification, as well as addressing cost/benefit issues of the treatments. This step is best organized as a workshop.
The terminology of CORAS is to a large degree taken from the standard (Standars Australia / Standars New Zealand 2004). Therefore, the conceptual foundation is to a large degree in accordance to this standard.
2.2. ISO/IEC 27001 (BS7799-2:2002)
ISO 27001 is a standard [ISO27001]. The risk assessment concerns a generic requirement that risk assessment has to be made through a recognized method but no support is provided.
The Risk treatment is a generic recommendation that risk treatment has to be made.
The risk acceptance concerns an indirectly implied through "statement of applicability".
This standard is dedicated to a process of certification. It enables the comparison of an information security management system through a series of controls. This standard does not cover risk analysis or certification of the Risk Management. Of UK origin, this standard has been adopted by ISO with some modifications. A certificate granted according to this standard confirms the compliance of an organization with defined requirements to information security management and a set of security controls.
2.3. Our methodology
Here some advantages/drawback points of each methods described below :
OCTAVE is a self-directed approach, meaning that people from an
organization assume responsibility for setting the organization's security strategy. OCTAVES is a variation of the approach tailored to the limited means and unique constraints typically found in small organizations (less than 100 people). OCTAVE is led by a small, interdisciplinary team (three to five people) of an organization's personnel who gather and analyze information, producing a protection strategy and mitigation plans based on the organization's unique operational security risks. To conduct OCTAVE effectively, the team must have broad knowledge of the organization's business and security processes, so it will be able to conduct all activities by itself.
CRAMM is a risk analysis method developed by the British government
organization CCTA (Central Communication and Telecommunication Agency), now renamed the Office of Government Commerce (OGC). A tool having the same name supports the method: CRAMM. The CRAMM method is rather difficult to use without the CRAMM tool. The first releases of CRAMM (method and tool) were based on best practices of British government organizations. At present CRAMM is the UK government's preferred risk analysis method, but CRAMM is also used in many countries outside the UK. CRAMM is especially appropriate for large organizations, like government bodies and industry.
Special Publication 800-series report gives very detailed guidance
and identification of what should be considered within a Risk Management and Risk Assessment in computer security. There are some detailed checklists, graphics (including flowchart) and mathematical formulas, as well as references that are mainly based on US regulatory issues.
The main innovations of the CORAS project stem from its emphasis on
integrating risk analysis tightly into a UML and RM-ODP setting, supported by an iterative process, and underpinned by a platform for tool-integration targeting openness and interoperability.
The standard ISO/IEC 27001 (BS7799-2:2002) does not cover risk
analysis or certification of the Risk Management.
What we need is a directed and detailed approach and NIST800-30 answers in big part to this. To evaluate the threat against TAS3 components, a methodology based on the book "Threat Modeling" [SwiderskiSnyder04] has been chosen. This threat modeling is quite similar to NIST800-30 but proposes deeper analysis that can be directly integrated with software development tool enabling threat modeling from design to test. Even if both approaches would be suitable, the latter has been chosen for pragmatic reasons: a European project already worked successfully with this methodology (the Mosquito Project). Then, to fulfill specificities of collaborative research projects, we slightly changed the approach. Indeed, threat modeling is generally used to study threats against an application or a system and to verify that common threat are correctly handled and mitigated. In TAS3, we focus on the threat model of the TAS3 components and are thus confronted to uncommon threats and mitigations.
The following methodology is used in this document:
Identify Components
Identify sub components and entry points
Identify Assets
Identify Threat
Identify Attacks
Identify Mitigation
Risk Assessment Methodology
For the different section, we propose a list of possible choices. These choice are just given as example, they may be not cover the entire spectrum of threats, attacks, or mitigation.
3.1. Identify the Components
The threat model is defined component by component since components can be reused in different applications and to let project partner work on their own component(s) in parallel.
Here the list of TAS3 components:
T3-ACVS: Authorization Credential Validation Service
T3-BP-CLIENT: Business Process User Interface
T3-BP-DEL: Business Process Delegation Service
T3-BP-ENGINE-ODE: Apache ODE Business Process Execution Engine
T3-BP-MGR: Business Process Administration Interface
T3-BP-PEP: Business Process Policy Enforcement Point
T3-BP-PIP: Business Process Policy Information Point
T3-BP-SMC: Business Process Security Configuration Component
T3-BUS-AUD: Audit Event Bus
T3-DEL: Delegation Service
T3-IDB-ACSIS
T3-IDP-SHIB: Shibboleth IDP
T3-IDP-SHIB-AGG: Enhancement to Shibboleth IDP to support attribute aggregation …
T3-LOG-SAWS: Secure Auditing Web Service
T3-LOG-WRAP-SAWS: Wrapper Web service around SAWS with extensions
T3-OCT: Online Compliance Testing
T3-OCT-PLANNER: Test Planner fo the Online Compliance Testing
T3-ONT-SER: Ontology Server
T3-PDP-BP: Business Process Policy Decision Point
T3-PDP-BTG: Break the Glass PDP
T3-PDP-M: Policy Decision Point/Master PDP
T3-PDP-P: PERMIS PDP
T3-PDP-T: Trust Policy Decision Point
T3-PEP-AI: Application-independent Policy Enforcement Point
T3-POL-GUI: Graphical Policy Editor
T3-POL-CNL: Controlled Natural Language Policy Editor
T3-POL-WIZ: Wizard Policy Editor
T3-PORT-JBOSS: JBOSS portal framework
T3-REP-FEDORA: TAS3 reference repository
T3-REP-JFEDORA: JFEDORA Library for TAS3 Generic Data Format
T3-SG-BASE: SOA Gateway Base System
T3-SG-WSP: SOA Gateway Web Service Provider
T3-SP-CVT: Europass CV Transcoding Web Service
T3-SP-MATCHER: Job Profile Matching Service
T3-STACK and T3-SSO-ZXID
T3-TPN-TB2: Trust Negotiation Module
T3-TRU-CTM: Credential based trust service
T3-TRU-KPI: Key Performance Indicators
T3-TRU-RTM: Reputation Trust Management Service
T3-ZXID-LINUX-X86: ZXID library and tools for TAS3 in apache, Java, PHP, and C
ZXID-SRC: Sources for the ZXID package
3.2. Identify the Sub Component
Each component offer different entry points, i.e. borderlines between the component and the external world that may be under attack. We distinguish two types of entry points: "intended" entry points, i.e. entry point that are visible to other trust domains (WS-Trust interface, etc.) and "internal" entry points that are not directly related to the TAS3 framework (http-level attacks, direct DB access, getting access to OS key store, etc.).
3.3. Identify the assets
Each component has assets, i.e. valuable pieces of information or functionalities that have to be protected against attackers. We can distinguish between functional assets, i.e. assets related to the application itself (e.g. medical data in e-health service), and non-functional assets, i.e. assets related to the TAS3framework itself. This document focuses on the TAS3 components and mainly describes non-functional assets. This is not covered by traditional approaches.
3.4. Indentify the Threats
A threat is a high-level description explaining what can go wrong (e.g. personal data disclosed, critical data destroyed). It is not directly related to the technology used to implement the component.
3.4.1. Auditing and Logging
User denies performing an operation
Attackers exploit an application without leaving a trace
Attackers cover their tracks
3.4.2. Authentication
Network eavesdropping
Brute force attacks
Dictionary attacks
Cookie replay attacks
Credential theft
3.4.3. Authorization
Elevation of privilege
Disclosure of confidential data
Data tampering
Luring attacks
3.4.4. Configuration Management
Unauthorized access to administration interfaces
Unauthorized access to configuration stores
Retrieval of plaintext configuration secrets
Lack of individual accountability
Over-privileged process and service accounts
3.4.5. Cryptography
Poor key generation or key management
Weak or custom encryption
Checksum spoofing
3.4.6. Exception Management
Attacker reveals implementation details
Denial of service
Sensitive Data
Access to sensitive data in storage
Network eavesdropping
Data tampering
3.4.7. Input/Data Validation
Buffer overflows
Cross-site scripting
SQL injection
Canonicalization
Query string manipulation
Form field manipulation
Cookie manipulation
HTTP header manipulation
3.4.8. Session Management
Session hijacking
Session replay
Man in the middle
3.5. Identify the Attacks
An attack is a concrete way to make a threat real (e.g. attacker gets access to personal databy…). Attacks can be related to the technology used to implement the component. Here some examples of potential attacks.
Buffer Overflow Attack
Canonicalization Attack
Chosen Plaintext Attack
Cross Site Scripting Attack
Denial of Service Attack
Forceful Browsing Attack
Format String Attack
HTTP Replay Attack
Integer Overflow Attack
LDAP Injection Attack
Man in the Middle Attack
Network Eavesdropping Attack
One-click Attack
Credentials Brute Force Attack
Password Dictionary Attack
Repudiation Attack
Response Splitting Attack
Server-side Code Injection Attack
Session Hijacking Attack
SQL Injection Attack
XML Injection Attack
3.6. Identify the mitigation
Mitigation is a mechanism to prevent the attack. Mitigations can be features of the framework (e.g. credentials are signed by issuers), can be mechanisms offered by underlying OS or network (e.g. private keys are stored in the machine's key store) or can be missing (e.g. not implemented). In this last case, the threat is not mitigated. However, it is useful to know that this threat exists. For instance, the fact that non-repudiation is not ensured for message X in component Y can be acceptable for a type of application but when the same component would be reused in another application, mitigation may be necessary.
For mitigation, the following are used:
[Implemented Mitigation] means that the mitigation is implemented and used in the demonstrator.
[Exisiting Mitigation] means that there is an existing mitigation that could be used without implementation specific toTAS3 . For instance using https or a firewall would mitigate the attack.
[Not implemented Mitigation ] means that the mitigation has not been implemented. A solution is known but more development is required to use it.
[No Mitigation] means that there is no solution to mitigate the attack. In this case the attack has to be “acceptable”.
When multiple mitigations exist, they are listed in the tree, i.e. by default there is an “or” operator between tree's nodes where Implemented or :( equals Implemented .
3.6.1. Input/Data Validation
Assume all input is malicious.
Centralize your approach.
Do not rely on client-side validation.
Be careful with canonicalization issues.
Reject known bad input
Constrain input.
Validate data for type, length, format, and range.
Reject known bad input.
Sanitize input.
Encrypt sensitive cookie state.
Make sure that users do not bypass your checks.
Validate all values sent from the client.
Do not trust HTTP header information.
Encrypt sensitive cookie state.
Do not trust fields that the client can manipulate (query strings, form fields, cookies, or HTTP headers).
Validate all values sent from the client.
Do not trust input
Consider centralized input validation.
Do not rely on client-side validation.
Be careful with canonicalization issues.
Constrain, reject, and sanitize input.
Validate for type, length, format, and range.
3.6.2. Authentication
Do not use passwords. Use hardware authentication tokens instead.
Separate public and restricted areas.
Use account lockout policies for end-user accounts.
Support password expiration periods.
Be able to disable accounts.
Do not store passwords in user stores.
Use strong passwords.
Do not send passwords over the wire in plaintext.
Protect authentication cookies.
Partition site by anonymous, identified, and authenticated area.
Support password expiration periods and account disablement.
Do not store credentials (use one-way hashes with salt).
Encrypt communication channels to protect authentication tokens.
Pass Forms authentication cookies only over HTTPS connections.
3.6.3. Authorization
Use multiple gatekeepers.
Restrict user access to system-level resources.
Consider authorization granularity.
Use least privileged accounts.
Consider authorization granularity.
Enforce separation of privileges.
Restrict user access to system-level resources.
3.6.4. Auditing and Logging
Audit and log access across application tiers.
Consider identity flow.
Log key events.
Secure log files.
Back up and analyze log files regularly.
Identify malicious behavior.
Know what good traffic looks like.
Audit and log activity through all of the application tiers.
Secure access to log files.
3.6.5. Configuration Management
Secure your configuration store.
Maintain separate administration privileges.
Use least privileged process and service accounts.
Do not store credentials in plaintext.
Use strong authentication and authorization on administration interfaces.
Do not use the LSA.
Secure the communication channel for remote administration.
Avoid storing sensitive data in the Web space.
3.6.6. Sensitive Data
Do not store database connections, passwords, or keys in plaintext.
Avoid storing secrets in the Local Security Authority (LSA).
Retrieve sensitive data on demand.
Encrypt the data or secure the communication channel.
Do not store sensitive data in persistent cookies.
Do not pass sensitive data using the HTTP-GET protocol.
Avoid storing secrets.
Secure the communication channel.
Provide strong access controls on sensitive data stores.
3.6.7. Session Management
Use SSL to protect session authentication cookies.
Encrypt the contents of the authentication cookies.
Limit session lifetime.
Protect session state from unauthorized access. Secure the channel.
Encrypt the contents of authentication cookies.
Protect session state from unauthorized access.
3.6.8. Cryptography
Do not develop your own cryptography.
Use the correct algorithm and correct key size.
Secure your encryption keys.
Use tried and tested platform features.
Keep unencrypted data close to the algorithm.
Cycle your keys periodically.
Store keys in a restricted location.
Exception Management
Do not leak information to the client.
Log detailed error messages.
Catch exceptions.
Use structured exception handling.
Do not reveal sensitive application implementation details.
Do not log private data such as passwords.
Consider a centralized exception management framework.
Risk Assessment of TAS3 components
The structure of each section is described below :
1) Component 1
1.1) listing entry points (and subcomponent with clear entry points)
1.1.1) Intended entry point 1
1.1.2) intended entry point 2
1.1.3) internal entry point 1
1.2) Asset 1 (of component 1)
1.2.1) Threat 1 (against Asset 1)
1.2.1.1) Attack 1 (implementing threat 1)
1.2.1.1.1) Mitigation 1 (preventing attack 1)
4.1.1.
4.2. T3-ACVS: Authorization Credential Validation Service
This is part of the T3-PEP-AI component.
4.3. T3-BP-CLIENT: Business Process User Interface
KARL
4.3.1. Entry points
Intended entry point: User interface
Intended entry point: SSO-related Communication with IdP
Intended entry point :Communication to BP-Engine - Starting process instances, creating and completing tasks
Internal entry point: Policy Store
Intended entry point : Decision requests to the T3-PDP-BP
4.3.2. [Assets] State of process instances, confidentiality and integrity of process data
Ability to start processes
Ability to complete tasks
Access to process data
4.3.2.1. [Threats] Unauthorized access to tasks (i.e., viewing or completing tasks).
4.3.2.1.1. [Attacks] Session hijacking attack
4.3.2.1.1.1. [Mitigation Implemented] Usage of SSL to protect session authentication cookies
4.3.2.1.1.2. [Mitigation Implemented] Limit session lifetime
4.3.2.2. [Threats] Phishing attack.
An attacker can present a site similar to the T3-BP-CLIENT to the user and make him confuse this fake site with the real site. It can thus trick him to enter confidential information because he believes a legitimate business process requests the information.
4.3.2.2.1.1. [Mitigation Implemented] Use SSL certificate
Use an SSL certificate to proof the site's identity. This should be accompanied by teaching users basic security precautions on the Web.
4.4. T3-BP-DEL: Business Process Delegation Service
KARL
4.4.1. Entry points
Intended entry point: Interface for re-assigning tasks to another user
Internal entry point: Decision requests to the T3-PDP-BP
Internal entry point: Registration of changed task assignment in the T3-BP-PIP
4.4.2. [Asset] Integrity of user-task assignment
The current functionality of the T3-BP-DEL is re-assignment of tasks from one user to another. Normally, requests to do so are authenticated and authorized.
4.4.2.1. [Threat] Assignment of tasks caused by other user than the current owner (or an authorized administrator)
4.4.2.1.1. [Attack] Pose as another user when requesting task-reassignment
4.4.2.1.1.1. [Existing mitigation] Use TAS3 authentication mechanism (identity assertions) to validate requests.
4.4.2.2. [Threat] Re-assignment of tasks to non-authorized users
4.4.2.2.1. [Attack] Spoof PDP response
4.4.2.2.1.1. [Implemented mitigation] PDP and T3-BP-DEL run on the same dedicated machine.
4.4.2.2.1.2. [Existing mitigitation] Encrypt and sign communication with PDP
4.5. T3-BP-ENGINE-ODE: Apache ODE Business Process Execution Engine
KARL
4.5.1. Entry points
Intended entry point: Process deployment
ii. Internal entry point: Interaction with BP-Client
iii. Internal entry point: Interfaces for communication with PEP
4.5.2. [Asset] Executable process models
Process models define the behavior of applications and deal with sensitive information.
4.5.2.1. [Threat] Flawed business process with unintended behavior
4.5.2.1.1. [Attack] Unauthorized deployment of of process models
4.5.2.1.1.1. [Implemented mitigation] Password authentication of
administrator access to process deployment
4.5.2.1.1.2. [Existing mitigation] Strong authentication (cryptographic identity assertions)
4.5.2.1.1.3. [Not implemented mitigation] Fine-grained authorization rules for process models.
4.5.2.1.1.4. [Not implemented mitigation] Logging of modifications to process models.
4.5.3. [Asset] Running process instances (state and data)
The engine executes instances of business processes. Correct application behavior relies on the state and data of these instances.
4.5.3.1. [Threat] Stopping running process instances
If running business process instances are stopped, they won't complete,
possibly causing inconsistent behavior, and preventing reaching the application goal.
4.5.3.1.1. [Attack] Unauthorized access to administration interface
4.5.3.1.1.1. [Implemented mitigation] Password authentication of administrator access to process deployment
4.5.3.1.1.2. [Existing mitigation] Strong authentication (cryptographic identity assertions)
4.5.3.1.1.3. [Not implemented mitigation] Fine-grained authorization rules for process models.
4.5.3.1.1.4. [Not implemented mitigation] Logging of modifications to process models.
4.6. T3-BP-ENGINE-ODE: Apache ODE Business Process Execution Engine
KARL
4.6.1. Entry points
Intended entry point: Process deployment
ii. Internal entry point: Interaction with BP-Client
iii. Internal entry point: Interfaces for communication with PEP
4.6.2. [Asset] Executable process models
Process models define the behavior of applications and deal with sensitive information.
4.6.2.1. [Threat] Flawed business process with unintended behavior
4.6.2.1.1. [Attack] Unauthorized deployment of of process models
4.6.2.1.1.1. [Implemented mitigation] Password authentication of administrator access to process deployment
4.6.2.1.1.2. [Existing mitigation] Strong authentication (cryptographic identity assertions)
4.6.2.1.1.3. [Not implemented mitigation] Fine-grained authorization rules for process models.
4.6.2.1.1.4. [Not implemented mitigation] Logging of modifications to process models.
4.6.3. [Asset] Running process instances (state and data)
The engine executes instances of business processes. Correct application
behavior relies on the state and data of these instances.
4.6.3.1. [Threat] Stopping running process instances
If running business process instances are stopped, they won't complete, possibly causing inconsistent behavior, and preventing reaching the application goal.
4.6.3.1.1. [Attack] Unauthorized access to administration interface
4.6.3.1.1.1. [[Implemented mitigation] Password authentication of administrator access to process deployment
4.6.3.1.1.2. [Existing mitigation] Strong authentication (cryptographic identity assertions)
4.6.3.1.1.3. [Not implemented mitigation] Fine-grained authorization rules for process models.
4.6.3.1.1.4. [Not implemented mitigation] Logging of modifications to process models.
4.7. T3-BP-MGR: Business Process Administration Interface
KARL
4.7.1. Entry points
Internal entry point: Communication with T3-BP-ENGINE-ODE
ii. Intended entry point: Graphical user interface
4.7.2. [Asset] Status of business process instances
The T3-BP-MGR will trigger adaption of business process models and
especially the migration of running business process instances to a new
version of a model.
4.7.2.1. [Threat] Unauthorized alteration of business process instances, unauthorized disclosure of process instance status.
4.7.2.1.1. [Attack] Spoofing identity of authorized user in communication between T3-BP-MGR and the engine.
4.7.2.1.1.1. [Existing mitigation] Strong authentication (cryptographic identity assertions)
4.7.2.1.2. [Attack] Illegitimate operations by authorized users.
The user might use a altered client software. If checks only occur at
client side, the user might be able to perform unauthorized actions in
the engine.
4.7.2.1.2.1. [Not implemented mitigation] Perform all necessary checks (also) on server side.
4.7.2.1.2.2. [Existing mitigation] Log all activities for audit purposes, limit the people allowed to perform management activities on the engine.
An attacker can try to provide the user with an altered client software,
which requests the user to authenticate normally, but makes other
requests than what the user thinks he has authorized.
4.7.2.1.3.1. [Existing mitigation] Control software installation on the user's computer.
If software installation is not controlled, the user's system has to be
considered insecure anyway, which makes it prone to all sorts of attacks.
4.8. T3-BP-PEP: Business Process Policy Enforcement Point
KARL
4.8.1. Entry points
Internal entry point: Communication between PEP and PIP
ii. Internal entry point: Communication between PEP and T3-BP-ENGINE-ODE
iii. Internal entry point: Communication with T3-PDP-BP (policy decision requests and responses)
4.8.2. [Asset] Correct policy enforcement
4.8.2.1. [Threat] A process communicates without policy enforcement
4.8.2.1.1. [Attack] Process models containing direct calls to third party web services, bypassing the PEP
4.8.2.1.1.1. [Implemented mitigation] Manual check of process models
4.8.2.1.1.2. [Not implemented mitigation] Automatic check of process models
4.8.2.1.1.3. [Not implemented mitigation] Integration of the PEP as a layer in the web service stack of the execution engine
4.8.2.1.2. [Attack] Calling the process' web service interfaces directly, bypassing the PEP
4.8.2.1.2.1. [Existing mitigation] Block access from outside using a firewall.
4.8.2.1.2.2. [Not implemented mitigation] Integration of the PEP as a layer in the web service stack of the execution engine
4.8.2.2. [Threat] Tricking PEP into using a rogue PDP
4.8.2.2.1. [Attack] Changing PDP address in PEP configuration.
4.8.2.2.1.1. [Implemented mitigation] Protect PEP code and configuration from unauthorized alteration using file system permissions.
4.9. T3-BP-PIP: Business Process Policy Information Point
KARL
4.9.1. Entry points
Internal entry point: Communication between PEP and PIP
ii. Communication with T3-BP-ENGINE-ODE
iii. Communication with PDP
4.9.2. [Asset] Correct information for policy enforcement
4.9.2.1.1. [Threat] Context information about processes not up to date
The context of a process (current point of execution, assigned users) continuously changes. Up-to-date information is necessary for correct policy enforcement.
4.9.2.1.2. [Attack] Interrupt communication between engine and PIP.
4.9.2.1.2.1. [Implemented mitigation] Run engine and PIP on the same dedicated machine.
This makes it much harder to interrupt communication.
4.9.2.1.2.2. [Existing mitigation] Enforce a time-to-live on information in the PIP, check directly on the engine if TTL is expired.
4.9.2.2. [Threat] PIP accepts and provides invalid/untrusted context information.
4.9.2.2.1. [Attack] Push incorrect context information to the PIP.
4.9.2.2.1.1. [Existing mitigation] Cryptographically sign messages to the PIP.
4.9.2.2.1.2. [Existing mitigation] Correctly configure trusted sources.
4.9.2.2.1.3. [Existing mitigation] Only accept input from the same host (using a firewall) which only runs BP-related component.
4.10. T3-BP-SMC: Business Process Security Configuration Component
KARL
The T3-BP-SMC processes security specifications for business processes (either as annotations or separate specifications) and translates them into business process related security configuration (e.g. business process policies) and enhances business process models with explicit security subprocesses.
4.10.1. Entry points
Intended interface: Security configuration user interface
ii. Intended interface: Processing of annotations to business process model security enhancements
iii. Intended interface: Processing of additional business process security configuration
iv. Internal interface: Deployment of security configuration to runtime components.
4.10.2. [Asset] Business process security annotations and security
4.10.2.1. [Threat] Inaccurate use of business process security annotations or specifications
4.10.2.2. [Attack] Process security modeler makes faulty or incomplete security annotations or specifications
4.10.2.2.1.1. [Mitigation] Process security modeler has to be trained for working with business process security annotations and specifications.
4.10.2.3. [Threat] Unauthorized modification of business process security annotations or specifications
4.10.2.3.1. [Attack] Unauthorized person changes the security configuration of a business process.
4.10.2.3.1.1. [Not implemented mitigation] User access control for SMC component, for business process models with security annotations and for security specification files.
4.10.3. [Asset] Security enhanced business process models and business process security configurations generated by the SMC component.
4.10.3.1. [Threat] Unauthorized modification of security enhanced business process models or security configurations.
4.10.3.1.1. [Attack] Unauthorized person changes the security configuration of a business process or the security enhanced business process itself.
4.10.3.1.1.1. [Not implemented mitigation] Secured deployment of business processes and appropriate security configurations from the SMC component to the business process engine (T3-BP-ENGINE-ODE): Webservice calls with signed file transfer.
4.10.3.1.1.2. [Implemented Mitigation] User access control on application and file system level for the business process engine.
4.11. T3-BUS-AUD: Audit Event Bus
NOT
4.11.1. Entry points
Intended Entry point: Interface with subscription clients
ii. Intended Entry point: Interface with notification clients
iii. Intended Entry point: Interface with update clients
4.11.2. [Asset] Channels of audit event type
4.11.2.1. [Threat] Overload of service creating failure in audit notifications
4.11.2.1.1. [Attack] Denial of service
4.11.2.1.1.1. [Not Implemented Mitigation]
To prevent a denial of service attack the services calling the audit bus will be limited to specific pre- authenticated TAS3 infrastructure services. Specific terms of behaviour will govern these services and the Audit Bus will be monitored to detect if a service making calls to the bus is in breach of these (an example could be behaviour that can be deemed as a denial of service attack). In this case the offending service will be reported to the appropriate authority and blacklisted from calling the bus. The architecture will also be designed to allow scaling and multiple audit bus implementations to manage load better.
4.11.3. [Asset] Status of audit event type
4.11.3.1. [Threat] Unauthorised invocation of the audit bus
4.11.3.1.1. [Attack] Unauthorised access to audit bus Web service interface
4.11.3.1.1.1. [Not Implemented Mitigation]
In order to update the status of an audit event or invoke the bus a token will be needed. The token is used to present the correct credentials to the audit bus server. This token comes from the main TAS3 authorisation infrastructure.
4.11.3.2. [Threat] Audit bus notification leak
4.11.3.2.1. [Attack] Unauthorised access to audit bus notifications
4.11.3.2.1.1. [Existing Mitigation]
4.12. T3-DEL: Delegation Service
SYMLABS, KARL
T3-IDP-ACIS: Authorization Credential Issuing Service (required, 90%)
T3-IDP-LASSO: Authentic IDP based on Lasso form Entr'Ouvert (optional, 10%)
4.12.1. Entry points
SOAP web interface
ii. Apache PHP client
iii. Shell or root shell administrative login
4.12.2. Assets
Issued credentials (these are cryptographically protected)
ii. Private signing key of the delegation issuing service
iii. Configuration file (list of trusted proxies)
iv. Trust store of the delegation issuing service (application server)
The delegation policy (this is cryptographically protected)
4.12.2.1. Threats
Unauthorized delegation
ii. Unauthorized revocation (leading to denial-of-service)
iii. Denial-of-service attack so that authorised requests will be denied
4.12.2.1.1. [Attack] Compromising the private signing key of the service
A compromise of the signing key of the delegation issuing service could lead to fake credentials being issued, and hence to unauthorized delegations.
4.12.2.1.1.1. [Existing Mitigation]
Keep the private key of the delegation issuing service in a password protected key store. Use file system permissions to prevent the service configuration file from being read by any entity except the application server running the service. Use an account with limited capabilities (no login shell) to run the application server. If no direct access to the delegation issuing service is required (e.g. when accessing service through a trusted proxy) the application server can be kept behind a firewall.
4.12.2.1.2. [Attack] Listing oneself as a trusted proxy
By definition, a trusted proxy is trusted to tell the delegation issuing service who the actual issuer is. If one can add oneself to the list of trusted proxies and obtain an SSL certificate that will be trusted by delegation issuing service (or its application server) then one can make false issuing requests (that will be accepted if they obey the delegation policy). Likewise, once the delegation issuing service is fooled into thinking that one is a trusted proxy, one can make bogus revocation requests.
4.12.2.1.2.1. [Existing Mitigation]
Use file system permission to prevent unauthorized modification of the service configuration file (which contains the list of trusted proxies). Alternatively digitally sign the configuration file. Or use a password protected trust store to prevent unauthorized modification of it. Use a reputable CA, or an in house CA (with an off line private key) to issue SSL certificates to the trusted proxies.
4.12.2.1.3. [Attack] Modifying or replacing the delegation policy
If one can modify the delegation policy then one can for instance add oneself as a trusted attribute issuer, or add oneself as a member of a specific domain etc.
4.12.2.1.3.1. [Implemented Mitigation]
Use a (self-signed) X.509 AC to hold the delegation policy. Use signature verification prior to loading the policy to ensure the integrity of the X.509 AC. Use file system permissions to protect the delegation issuing service's configuration files from unauthorized modification. This configuration file contains the policy reference, policy location and the certificates that are the roots of trust of the signature verification process.
4.12.2.1.4. [Attack] Gaining access to the credential repository
Since the credentials are digitally signed then it is not possible to either modify a credential or mint a new one without access to the signing key. If an attacker gains access to the credential repository she can only delete the credentials in the repository. This will have the effect that legitimate access requests will be denied by a PDP when configured to pull from this repository.
4.12.2.1.4.1. [Existing Mitigation]
Restrict access to the credential repository by for instance keeping it behind a firewall. When using an LDAP repository configure it so that the login credentials given write access to the repository cannot be obtained by simply sniffing the network.
4.12.2.1.5. [Attack] Obtain the password of a legitimate user of the DIS client
Once an attacker has obtained the password of a legitimate user of the DIS client, then she can make false delegation requests.
4.12.2.1.5.1. [Existing Mitigation]
Use an SSL connection to protect the password from being visible on the Internet. Configure the (Apache) web server to not serve the DIS client pages on a http only connection. Ensure that user passwords are strong and impossible to dictionary attack.
4.13. T3-IDP- ACSIS
SYMLABS,
4.13.1. Entry points
Shell or root shell (or ssh) administrative login
TAS3 designed management interfaces (none yet)
Product specific management interfaces
New user registration (feature to allow anonymous new user to self register)
Auto-CoT (fully automatic metadata exchange and trust establishment with anonymous third party SPs)
New service registration (feature to allow anonymous 3rd party to register new services)
Web GUI
SOAP web service
SSO
SLO
Discovery query
4.13.2. Data assets
Private keys of the service itself
Circle-of-Trust database
Discovery Registrations
User database
User names
Authentication credentials (password hash, Yubikey shared secret)
User's attribute data
Federation database: name id mappings
Session store
4.13.3. Nonfunctional assets
Privacy preserving through avoidance of correlation handles
User consent and control of data release
Organizational control of data release
Nonrepudiation
Accountability
Credible authentication of users
Credible authentication of system entities
4.13.4. Attacks and mitigation
Too numerous to describe exhaustively in one afternoon *** TBD
Generally the data assets are protected using Unix filesystem permissions against shell and local Unix process access. This, of course, is of little value against root. Therefore deployment MUST use nonroot users for running all TAS3 related processes as well as for most administrative tasks.
The TAS3 designed and product specific management interfaces follow good coding practises (e.g. check for ".." in path) to only allow designed access to the data assets.
Web GUI is coded such that only authorized accesses are possible
SOAP web service is coded such that only authorized accesses are possible
Appropriate crypto layer (such as TLS) is applied in Web GUI, SOAP, and ssh entry points
4.14. T3-IDP-SHIB: Shibboleth IDP
KENT
4.14.1. Entry Points
SOAP Authentication Service Endpoint
ii. SOAP Attribute Authority Endpoint
iii. Shell or root shell administrative login
4.14.2. [Asset] Issued Credentials
4.14.2.1. [Threat] Issues Credentials used by More than One Party
4.14.2.1.1. [Attack] Replay Attack
If intercepted by a third party, credentials may be submitted to the SP at which they are valid multiple times. Without adequate replay protection this may allow multiple users to access the service using the same set of credentials
4.14.2.1.1.1. [Existing Mitigation] Replay Detection
Implement checks at the SP to log the details of each incoming message so that if the same message is passed to the SP multiple times it can be recognised and the presenter denied access.
4.14.3. [Asset] Private Signing Keys of the Service
4.14.3.1. [Threat] Private Signing Key of the Service is Compromised
A compromise of the signing key of the modified IdP could lead to fake attribute or authorisation credentials being issued, and allow an untrusted service to masquerade as the IdP entity.
4.14.3.1.1. [Attack] Attacker Gains Access to Machine Hosting the Service
4.14.3.1.1.1. [Existing Mitigation] Use Password Protected Key Store
Keep the private key of the IdP in a password protected key store.
4.14.3.1.1.2. [Existing Mitigation] Use File System Permissions
Use file system permissions to prevent the service configuration file from being read by any entity except the application server running the service.
4.14.3.1.1.3. [Existing Mitigation] Use Restricted Account
Use an account with limited capabilities (no login shell) to run the application server.
4.14.3.1.1.4. [Existing Mitigation] Restrict Access to Service
If no direct access to the IdP is required (e.g. when accessing service through a trusted proxy) the application server can be kept behind a firewall.
4.14.4. [Asset] User Database (Attributes and Authentication Credentials)
4.14.4.1. [Threat] User Authentication Credentials are Compromised
Once an attacker has obtained the password of a legitimate user of the IdP client, then she can masquerade as the user throughout the federation.
4.14.4.1.1. [Attack] Dictionary attack
An attacker may attempt to obtain the username / password combination of a legitimate user of the IdP by performing a dictionary attack on the authentication page.
4.14.4.1.1.1. [Implemented Mitigation] Restriction of Number of Authentication Requests
The authentication endpoint should monitor the number of authentication attempts that are made for each incoming authentication session. After a configurable number of failed authentication attempts have been made the authentication attempt should fail and return an error message to the requesting SP.
4.14.4.1.2. [Attack] Network Sniffing
4.14.4.1.2.1. [Implemented Mitigation] Use SSL/TLS connection
Use an SSL connection to protect the password from being visible on the Internet. Configure the (Apache) web server to not serve the IdP authentication pages on a http only connection.
4.14.4.1.2.2. [Implemented Mitigation] Use Different Authentication Mechanism
Implement two factor or challenge/response authentication mechanisms to increase the user's level of assurance.
4.14.4.2. [Threat] IdP Assertions are Reused (Credential Theft)
4.14.4.2.1. [Attack] Assertions are Stolen
Once issued by the IdP attribute and authorisation credentials may be stolen in transit by an intermediary and presented to another SP in order to grant another user access.
4.14.4.2.1.1. [Implemented Mitigation] Limited Life Time
Every credential should be short lived to prevent an attacker having unlimited time to reuse the credential.
4.14.4.2.1.2. [Implemented Mitigation] Restrict SPs at which Assertion is valid
Each credential should be encrypted to the intended recipient making the credential worthless to all but the intended recipient. SPs should obey any audience restriction present in the assertion.
4.14.4.2.1.3. [Implemented Mitigation] Tie Authentication and Attribute Assertion Together
Each attribute credential should contain a Subject that is identical to that of the Subject of the preceding authentication assertion to prevent it from being used as part of a different session.
4.14.4.3. [Threat] User Attributes are Disclosed to Unauthorised Party
User attributes should not be disclosed to unauthorized parties.
4.14.4.3.1. [Attack] Network Sniffing
4.14.4.3.1.1. [Implemented Mitigation] Use of Cryptographic Techniques
All incoming messages are encrypted using the IdPs public key and the IdP encrypts all outgoing messages using the public key of the recipient SP.
4.14.4.4. [Threat] Compromise of Backend Database/LDAP Server
If an attacker can access or modify the backend database/LDAP server then she may be able to edit the credentials.
4.14.4.4.1. [Attack] Unauthorised Access Gained to Backend Data Store
4.14.4.4.1.1. [Existing Mitigation] Use of Firewall
Use a firewall to restrict access to the backend data store. This need not be accessible from the Internet, even if the IdP has to be.
4.14.4.4.1.2. [Existing Mitigation] Use of SSL/TLS
When administrator access is needed to the backend data store, then the credentials should not be conveyed in clear text. Communication with the database should either be local or over SSL.
4.14.5. [Asset] Session Information
4.14.6. [Asset] Configuration Files of the Service
4.14.6.1. [Threat] Unauthorised Modification of the Configuration Files
If an attacker can modify the IdPs configuration files then they can edit the attributes that will be released from the IdP, add additional un-trusted attribute sources, or remove security precautions such as the signing and encryption of outgoing messages.
4.14.6.1.1. [Attack] Attacker Gains Unauthorised Access and Modifies Configuration Files
4.14.6.1.1.1. [Existing Mitigation] Use of File System Permissions
Use file system permissions to prevent the service configuration files from being read by any entity except the application server running the service.
4.14.6.1.1.2. [Existing Mitigation] Use of Restricted Account
Use an account with limited capabilities (no login shell) to run the application server.
4.14.7. [Non-functional Asset] User Consent and Control of Data Release
4.14.8. [Non-functional Asset] Organisation Control of Data Release
4.15. T3-IDP-SHIB-AGG: Enhancement to Shibboleth IDP to support attribute aggregation …
KENT
Please note: The more general risk analysis presented in Section 4.13 for the Shibboleth IdP also applies to this section. The additional risks presented below apply only to the changes required to support aggregation.
4.15.1. Entry points
SOAP web interface for auditing
ii. SOAP web interface for enquiries
iii. Administrative shell login
iv. Application management console of application server
4.15.2. [Asset] The Audit Trail
4.15.2.1. [Threat] Modification of Audit Trail
4.15.2.1.1. [Attack] Attacker Accesses Auditing Service Machine and Modifies/Deletes the Audit Trail
An attacker may gain unauthorized access to the machine hosting the logging service. In this way she may be able to modify or remove the audit trail.
4.15.2.1.1.1. [Implemented Mitigation] Cryptographic Protection
The SAWS audit trail structure uses cryptographic techniques to ensure that unauthorized modification of the audit trail will not go unnoticed. It uses heartbeats to ensure that records are not removed from the end. It chains audit files together to ensure that complete audit files cannot be deleted without notice. It periodically creates new audit files to ensure they do not become too long.
4.15.2.1.1.2. [Existing Mitigation] File System Permissions
Use file system permissions to restrict access to the audit trail, e.g. only allow the application server's account to write to the file.
4.15.2.1.1.3. [Existing Mitigation] Use Restricted Account
Run the application server with a restricted account (e.g. an account without a login shell). Restrict access to the machine hosting the logging service by e.g. running it behind a firewall if possible.
4.15.2.1.1.4. [Existing Mitigation] Backup the Audit Trail
Periodically backup complete audit files to CD-ROM or similar to prevent loss or modification in case of an attack.
4.15.2.2. [Threat] Unauthorised Disclosure of Audit Trail Contents
4.15.2.2.1. [Attack] Attacker Obtains Complete Copy of Audit Trail
If the machine hosting the audit service (or one of the machines holding the backup of the audit trail) is compromised then it may be possible that the attacker gets to read access to audit information that she shouldn't be able to read.
4.15.2.2.1.1. [Implemented Mitigation] Encryption of Audit Trail Data
If confidentiality of the audited data is important then the audit service can be configured to encrypt the audited data with a symmetric key. This symmetric key is stored in the audit trail, encrypted with the public key of the persons authorised to read the contents of the trail. In this way, the audit trail is not readable by subjects not having one of the correct private keys.
4.15.2.2.2. [Attack] Attacker Abuses the Enquiry Service
An attacker may abuse the enquiry service by issuing search requests for data that she isn't allowed to see.
4.15.2.2.2.1. [Existing Mitigation] Use Authorisation on Enquiry Service
The enquiry service is still in an embryonic state of implementation, but it is envisaged that a PDP will be used both before searching the audit trail and to filter the results returned to the requester. The enquiry service will run over SSL and will require client authentication, possibly using a list of trusted proxies to say who the actual requester is.
4.15.3. [Asset] SAWS Records a Secure Audit Trail
4.15.3.1. [Threat] Denial of Service for Legitimate Clients
4.15.3.1.1. [Attack] Attacker Swamps Service with Requests
4.15.3.1.1.1. [Implemented Mitigation] Only Allow Known Clients
The auditing service only accepts messages from known clients. This is ensured by configuring the application server to run the auditing service over SSL only. The application server has to be configured to require client authentication. Configure the trust store to only accept messages from clients having a certificate issued by a trusted CA. Further, the SAWS configuration file contains a list of known clients; only these are allowed to add messages to the audit trail.
4.15.3.1.1.2. [Existing Mitigation] Use Firewall
When the IP-addresses of the attacker are known these can already be blocked on the level of the (operating-system) firewall, so that they never reach the application server.
4.15.4. [Asset] Private Keys for Signing/Encrypting
4.15.4.1. [Threat] Compromise of the Private Signing or Encryption Key
4.15.4.1.1. [Attack] Attacker Gains Access to Machine Hosting Auditing Service
An attacker may gain access to the machine hosting the audit service and in this way obtain a copy of service's secrets. For instance, if a copy of the private signing key is obtained, then an attacker would be able to modify the audit trail without this being noticed.
4.15.4.1.1.1. [Implemented Mitigation] Use of Password Protected Key Stores
Use password protected key stores (which can optionally require more than one password to be opened) to hold the service's secrets. The passwords are asked for interactively and are not stored in the configuration file. Only when automatic (i.e. without human intervention) start up of the service is required do you need to store passwords in a file. This file should be properly protected using file system permissions and should only be readable by the application server hosting the audit service.
4.15.4.1.1.2. [Existing Implementation] Use of TPM to Store Secrets
The encrypted software keystore could be replaced with a hardware TPM based keystore which will forbid tampering or unauthorised access.
4.16. T3-LOG-SAWS: Secure Auditing Web Service
KENT
4.16.1. Entry points
SOAP web interface for auditing
ii. SOAP web interface for enquiries
iii. Administrative shell login
iv. Application management console of application server
4.16.2. [Asset] The Audit Trail
4.16.2.1. [Threat] Modification of Audit Trail
4.16.2.1.1. [Attack] Attacker Accesses Auditing Service Machine and Modifies/Deletes the Audit Trail
An attacker may gain unauthorized access to the machine hosting the logging service. In this way she may be able to modify or remove the audit trail.
4.16.2.1.1.1. [Implemented Mitigation] Cryptographic Protection
The SAWS audit trail structure uses cryptographic techniques to ensure that unauthorized modification of the audit trail will not go unnoticed. It uses heartbeats to ensure that records are not removed from the end. It chains audit files together to ensure that complete audit files cannot be deleted without notice. It periodically creates new audit files to ensure they do not become too long.
4.16.2.1.1.2. [Existing Mitigation] File System Permissions
Use file system permissions to restrict access to the audit trail, e.g. only allow the application server's account to write to the file.
4.16.2.1.1.3. [Existing Mitigation] Use Restricted Account
Run the application server with a restricted account (e.g. an account without a login shell). Restrict access to the machine hosting the logging service by e.g. running it behind a firewall if possible.
4.16.2.1.1.4. [Existing Mitigation] Backup the Audit Trail
Periodically backup complete audit files to CD-ROM or similar to prevent loss or modification in case of an attack.
4.16.2.2. [Threat] Unauthorised Disclosure of Audit Trail Contents
4.16.2.2.1. [Attack] Attacker Obtains Complete Copy of Audit Trail
If the machine hosting the audit service (or one of the machines holding the backup of the audit trail) is compromised then it may be possible that the attacker gets to read access to audit information that she shouldn't be able to read.
4.16.2.2.1.1. [Implemented Mitigation] Encryption of Audit Trail Data
If confidentiality of the audited data is important then the audit service can be configured to encrypt the audited data with a symmetric key. This symmetric key is stored in the audit trail, encrypted with the public key of the persons authorised to read the contents of the trail. In this way, the audit trail is not readable by subjects not having one of the correct private keys.
4.16.2.2.2. [Attack] Attacker Abuses the Enquiry Service
An attacker may abuse the enquiry service by issuing search requests for data that she isn't allowed to see.
4.16.2.2.2.1. [Existing Mitigation] Use Authorisation on Enquiry Service
The enquiry service is still in an embryonic state of implementation, but it is envisaged that a PDP will be used both before searching the audit trail and to filter the results returned to the requester. The enquiry service will run over SSL and will require client authentication, possibly using a list of trusted proxies to say who the actual requester is.
4.16.3. [Asset] SAWS Records a Secure Audit Trail
4.16.3.1. [Threat] Denial of Service for Legitimate Clients
4.16.3.1.1. [Attack] Attacker Swamps Service with Requests
4.16.3.1.1.1. [Implemented Mitigation] Only Allow Known Clients
The auditing service only accepts messages from known clients. This is ensured by configuring the application server to run the auditing service over SSL only. The application server has to be configured to require client authentication. Configure the trust store to only accept messages from clients having a certificate issued by a trusted CA. Further, the SAWS configuration file contains a list of known clients; only these are allowed to add messages to the audit trail.
4.16.3.1.1.2. [Existing Mitigation] Use Firewall
When the IP-addresses of the attacker are known these can already be blocked on the level of the (operating-system) firewall, so that they never reach the application server.
4.16.4. [Asset] Private Keys for Signing/Encrypting
4.16.4.1. [Threat] Compromise of the Private Signing or Encryption Key
4.16.4.1.1. [Attack] Attacker Gains Access to Machine Hosting Auditing Service
An attacker may gain access to the machine hosting the audit service and in this way obtain a copy of service's secrets. For instance, if a copy of the private signing key is obtained, then an attacker would be able to modify the audit trail without this being noticed.
4.16.4.1.1.1. [Implemented Mitigation] Use of Password Protected Key Stores
Use password protected key stores (which can optionally require more than one password to be opened) to hold the service's secrets. The passwords are asked for interactively and are not stored in the configuration file. Only when automatic (i.e. without human intervention) start up of the service is required do you need to store passwords in a file. This file should be properly protected using file system permissions and should only be readable by the application server hosting the audit service.
4.16.4.1.1.2. [Existing Implementation] Use of TPM to Store Secrets
The encrypted software keystore could be replaced with a hardware TPM based keystore which will forbid tampering or unauthorised access.
4.17. T3-LOG-WRAP-SAWS: Wrapper Web service around SAWS with extensions
Unikold
4.17.1. Entry points
SOAP client
4.17.2. [Assets]: Audit Trails
4.17.2.1. [Threat[: Traceless Exploitation
4.17.2.1.1. [Attack]: Attackers exploit an application without leaving a trace
4.17.2.1.1.1. [Mitigation]: Identify malicious behaviour.
4.17.2.2. [Threat]: Disguising the attack
4.17.2.2.1. [Attack]: Attackers cover their tracks
4.17.2.2.1.1. [Existing Mitigation]: Using audit/log files
4.17.2.2.1.2. [Existing Mitigation]: Audit and log activity through all of the application tiers.
4.17.2.2.1.3. [Existing Mitigation]: Secure access to log files.
4.18. T3-OCT: Online Compliance Testing
CNR
The TAS3 architecture supports a novel testing approach for services that are running within a TAS3 choreography. Such approach is implemented within the TAS3 architecture by the OCT (On-line Compliance Testing) component. The novel idea behind OCT is that services are submitted to the execution of a set of test cases in their real execution environment, while they possibly interact with other services. The service under tests are unaware that some invocation they receive comes from OCT. OCT validation may be performed periodically or after some relevant event, aiming at verifying that every service in the TAS3 federation abides by the manifested policies and/or complies with the functional specifications. As detailed in D10.2, on-line testing in TAS3 is applied in order to reduce the risk that services within a circle of trust (i.e. service federation) will get in contact with unreliable services. Therefore services within the federation will be regularly submitted to on-line testing to assess that they comply with their public and manifested policies. Also, the scenario we foreseen for OCT assumes that, within the federation, services admit that different requesters may play different roles. Service clients collect credentials in order to prove the role that they are playing as requesters. Thus, the authorization/authentication layers in TAS3 (e.g. the IdP components) collaborates with OCT components signing role assertions that would be used in running the test cases.
Note that the OCT components uses the security layer provided by the TAS3 architecture. Thus it exists a strict dependency in term of security vulnerabilities with the issues described for the T3-STACK and the component T3-SSO-ZXID (see Section 4.39).
4.18.1.1. [Intended Entry Points]
SOAP Binding with the IdP
4.18.1.2. [Internal Entry Points]
The API of the OCT component, used in order to implement the test-driver
4.18.2.1. [Non-Functional Assets]
ii. the OCT component credentials
iii. user/test user credentials
iv. 4.18.1.1.3 QoS of the service under test
The following threats are relate to the non functional assets
The service under test have to be unaware of the TAS3 testing session, the credential issued for testing purposes can be actually spent as valid credential within the federation.Malicious services may obtain from the IdP credential that was originally issued only for testing purposes and use them illicitly.
4.18.2.2.1. [Attack ]Man in the middle
Malicious services can sniff the communication between the OCTcomponent and the IdPs in TAS3
4.18.2.2.2. [Attack ]Spoofing
Malicious services masquerade their interaction to the IdP as the OCT component.
4.18.2.2.2.1. [ Implemented Mitigation ]
Usage of SSL or TLS Client Certificate toprotect session authentication in the communication between the OCT component and the IdPs.
Use the security assets of the TAS3-STACK
Limit session lifetime
4.18.2.3. [ Threat ]
A massive use of the on-line testing process can affect the QoS of the service under test.
4.18.2.3.1. [ Attack ]Denial of Service (DoS)
Malicious services that have gained the OCT credential can exploit them running Denial-Of-Services attacks to other services in the TAS3 choreography
4.18.2.3.1.1. [ Implemented Mitigation ]
Use the security assets of the TAS3- STACK
4.18.2.4. [ Threat ]
The credential used during an on-line testing session may have undesired effect on actual users.
The threat 4.18.2.5 does not refer to any specific attack.However, as potential errors and failures of the on-line testing activity may generate unconsidered security leak affecting real user, we recommended some implemented mitigations for this threat
4.18.2.4.1.1. [Implemented Mitigation ]
Create and use realistic test user
4.19. T3-OCT-PLANNER: Test Planner for the Online Compliance Testing
The TAS3-OCT-PLANNER is an off-line component. With respect to the TAS3 Architecture it belongs to the Modeling & Configuration Management
Realm. In particular, the TAS3-OCT-PLANNER can be used off-line in order to moel test cases, and it is not affected by run-time security issues.
4.20. T3-PDP-BP: Business Process Policy Decision Point
KARL
The need of this component is currently not clear; see PDP-M and PDP-P for possible attacks;
4.21. TAS3-ONT-SER: Ontology Server
VUB
4.21.1. Entry Points
Command line access
J2EE Interface: uses JBoss, which provides means for security (authentication, etc.)
4.21.1.1. Intended Entry point:
J2EE Bean delegating calls to internal beans
LEXONBASE (CRUD LEXON & CONTEXT)
COMMITMENT (CRUD COMMITMENT)
VERSIONNING (prototype)
PERSPECTIVE CONFLICT MANAGEMENT (prototype)
4.21.2. [Asset] Ontology Server
4.21.2.1. [Threat] Trust Policy Disclosure/Modification (heading4)
4.21.2.1.1. [Attack] The administrator access to the repository and disclose/change the trust policies
4.21.2.1.1.1. [Existing Mitigation] External Monitoring and Logging mechanism
Standard provided by JBoss for the application server
WEB CONSOLE + logging via shell
Keeping of who modified what in the business layer
4.21.2.1.2. [Attack] Unauthorized access to the ontology server
4.21.2.1.2.1. 1.1.2.1.2.1. [Existing Mitigation] Logging and monitoring mechanisms
The data assets are stored in a Postgres database on a Linux server, which is protected through the login to the database.
The J2EE interface uses username and passwords to enable authorised access to the data.
The REST interface will be implemented and will give authorised access to people with the right credentials/tokens.
4.21.2.1.2.2. [Existing Mitigation ] Use of authorization mechanisms
provided by JBoss
IP blocked for 10 minutes after 3 unsuccessful logins (prevent intrusion)
no open ports
4.21.2.1.3. [Attack] forcing the access to the database
4.21.2.1.3.1. [Existing Mitigation] Use of secure channels for data transmissions (i.e. HTTPS)
4.22. T3-PDP-BTG: Break the Glass PDP
KENT
This is part of theT3-PEP-AI component. Here we discuss an additional asset specific to the T3-PDP-BTG
4.22.1. Entry points
See entry points of T3-PEP-AI.
4.22.2. [Asset] The BTG-State of the System
4.22.2.1. [Threat] Unauthorised Modification of the BTG-State
When an attacker manages to modify the BTG state, then she may be able to get access to certain resources without actually breaking the glass, hereby circumventing any obligations (such as audit and notification) that may be associated with breaking the glass.
4.22.2.1.1. [Attack] Gain Access to Machine Hosting BTG-State and Modify It
4.22.2.1.1.1. [Existing Mitigation] In-Memory Only Implementation
The BTG-state is implemented in-memory only, making it hard for an attacker to modify it as the operating system manages the boundaries between the memory areas assigned to different applications.
4.23. T3-PDP-M: Policy Decision Point/Master PDP
KENT
This is part of theT3-PEP-AI component.
4.24. T3-PDP-P: PERMIS PDP (optional, 1PM to do)
Kent
4.24.1. Entry Points
Java API
4.24.2. [Asset] Authorisation Policy
4.24.2.1. [Threat] Policy is Modified
4.24.2.1.1. [Attack] Attacker Modifies Authorisation Policy
An attacker tries to edit the authorisation policy in order to grant access to people who should not have access or deny access to people who should have access.
4.24.2.1.1.1. [Implemented Mitigation] Cryptographic Protection
The PERMIS policy is designed to be digitally signed and the PERMIS engine validates the signature at start up time. Hence an attacker would need to gain access to the private key of the policy author in order to effectively edit the policy.
4.25. T3-PDP-T: Trust Policy Decision Point
TUE
4.25.1. Entry points
Internal Entry point: Shell or root shell
ii. Intended Entry point: Trust PDP Evaluation Request
iii. Intended Entry point: Trust PDP Call-back Function
iv. Intended Entry point: Returned value from Trust Service call
Intended Entry point: Trust Policy Repository Interfaces
4.25.2.1. [Threat] Trust Policy Disclosure/Modification
A malicious agent accesses the trust policies and discloses or manipulates them. Like any policies, manipulation needs to be prevented and the policies are sensitive information that should be protected from being revealed.
4.25.2.1.1. [Attack] Malicious administrator
A malicious administrator accesses to the repository and discloses/changes the trust policies.
4.25.2.1.1.1. [Existing Mitigation]
External monitoring and logging mechanisms to track the administrator's activities. These mechanisms should be external to the Trust-PDP in order to avoid their manipulation performed by the administrator.
4.25.2.1.2. [Attack] Unauthorized access
A malicious agent gains access to the trust policy repository to disclose/change the trust policies.
4.25.2.1.2.1. [Existing Mitigation]
Logging and monitoring mechanisms to track the access records and to detect illegal behaviours.
4.25.2.1.2.2. [Existing Mitigation ]
Use of authorization mechanisms to control the access to the trust policy repository.
4.25.2.1.3. [Attack] Man in the Middle or network eavesdropping
A malicious agent gains the access to the trust policies during the querying/updating process.
4.25.2.1.3.1. [Existing Mitigation]
Use of secure channels for data transmissions (i.e. HTTPS).
4.25.3. [Asset] Trust-PDP Evaluation Service
4.25.3.1. [Threat] Trust-PDP service not available
A malicious agent makes the Trust-PDP unavailable for the intended users.
4.25.3.1.1. [Attack] Denial of Service (DOS) attack
A malicious agent or a collectiveness of malicious agents saturates the Trust-PDP evaluation service with a huge amount of requests.
4.25.3.1.1.1. [Implemented Mitigation]
The existence of monitoring and logging mechanisms to trace suspect behaviours.
4.25.3.1.1.2. [Existing Mitigation ]
The utilization of a firewall for the input/output traffic filtering.
4.25.3.1.1.3. [Existing Mitigation]
Geographically restrictions on access domain: the service is made available only to well known locations where requests are expected from.
4.25.3.2. [Threat] Unauthorized Access to the Trust PDP evaluation service
A malicious agent uses the Trust-PDP evaluation service, sending requests and obtaining responses to use for malevolent purposes.
4.25.3.2.1. [Attack] Brute Force or Password Dictionary
A malicious agent obtains the access performing a brute force attack (trying all the possible passwords) or a password dictionary attack (trying with the most likelihood passwords).
4.25.3.2.1.1. [Existing Mitigation ]
Mechanisms that press for the usage of strong and effective passwords.
4.25.3.2.1.2. [Mitigation Implemented]
Logging and monitoring mechanisms to detect possible misbehaviours.
4.25.3.2.1.3. [Mitigation Implemented]
Single Sign On (SSO) authorization mechanisms to automatically and safely generate strong and secure tokens.
4.25.3.3. [Threat] Request/Response Modification
A malicious agent changes the request or the response in order to manipulate the results of the evaluation.
4.25.3.3.1. [Attack] Parameter Tampering or Man in the Middle.
A malicious agent gains the access to the messages exchanged during a request/response process and alters such messages in a malevolent way.
4.25.3.3.1.1. [Existing Mitigation]
Data integrity check mechanisms to verify that a response is feasible for a given request.
4.25.3.3.1.2. [Existing Mitigation]
Mechanisms to link the response message to its associated request message.
4.25.3.3.1.3. [Existing Mitigation]
Use of secure channels for data transmissions (i.e. HTTPS)
4.26. T3-PEP-AI: Application-independent Policy Enforcement Point
4.26.1. Entry Points
SOAP web interface
ii. Administrative shell login
4.26.2. [Asset] Built-in Policies
4.26.2.1. [Threat] Unauthorised Modification of Built-in Policies
4.26.2.1.1. [Attack] Attacker manages to replace the policy contents of a built-in policy
If an attacker gains access to the machine hosting the policies (which is not necessarily the same as the machine hosting the AIPEP) then maybe she can replace a built-in policy with one of her own making.
4.26.2.1.1.1. [Implemented Mitigation] Cryptographic Protection
For PERMIS policies this attack is defended against by encapsulating the policy in a (self signed) X.509 Attribute Certificate. The cryptographic signature on the X.509 AC prevents tampering with its contents.
4.26.2.1.1.2. [Existing Mitigation] File System Permissions
For other policy formats, in particular XACML policies for the Sun XACML PDP or for the trust PDP, no such cryptographic protection exists at the moment. File system permissions can give some protection: the policies should only be readable (and not even writeable) by the AI-PEP itself.
4.26.3. [Asset] Configuration File
4.26.3.1. [Threat] Unauthorised Modification of Configuration File
4.26.3.1.1. [Attack] Attacker Modifies Configuration File
If an attacker gains access to the machine hosting the AI-PEP, then she may be able to modify the configuration file e.g. to load an additional policy or to remove a policy which would deny her access.
The configuration file also contains the roots of trust for signature verification, so the attacker might also able to add a PKC of her liking to as a root of trust.
4.26.3.1.1.1. [Existing Mitigation] File System Permissions
Use file system permissions to protect the configuration file from being changed. Configuration file should only be readable by account running the AI-PEP service.
4.26.3.1.1.2. [Existing Mitigation] Use Restricted Account
The AI-PEP service should be run under an account with very few permissions, e.g. without remote login capabilities.
4.26.4. [Asset] Roots of Trust (PKCs) for Signature Verification
4.26.4.1. [Threat] Attacker Adds/Deletes/Replaces the PKCs used for Signature Verification
4.26.4.1.1. [Attack] Attacker Gains Access to Machine with PKCs and Modifies Them
4.26.4.1.1.1. [Existing Mitigation] File System Permissions
4.26.4.1.1.2. [Existing Mitigation] Use a Password Protected Trust Store
Keeping the PKCs in a password protected trust store requires the attacker to guess the password for the trust store (or otherwise break its security).
4.26.4.1.1.3. [Existing Mitigation] Use Restricted Account
4.26.5. [Asset] System Coordinates Decision Making
4.26.5.1. [Threat] System Crashes
4.26.5.1.1. [Attack] An Attacker Crafts a Malicious Message in Order to Crash the System
An attacker might attempt to send an authorization request (or a request to validate some credentials) to is formed in such a way as to make the server crash.
4.26.5.1.1.1. [Implemented Mitigation] Use of Schema Checking
The system is built in such a way that only requests conforming to the schema ever reach the server. A SOAP message not conforming to the schema is discarded by the Axis2 SOAP layer around the actual server.
4.26.6. [Asset] The Sticky Store
4.26.6.1. [Threat] Unauthorised Modification of Sticky Store
Since the sticky store holds the binding between resources and the policies applicable to them, modifying this store might get an attacker unauthorised access to resources.
4.26.6.1.1. [Attack] Attacker Modifies the Sticky Store by Gaining Access to the Machine Hosting the Sticky Store
4.26.6.1.1.1. [Non existing Mitigation] Use Proper Access Control to Sticky Store
The sticky store hasn't been fully implemented yet. A first version will be a simple in-memory implementation of the sticky store which is by definition hard to modify for an attacker. However, once a persistent implementation (e.g. by using a relational database) is used then proper access controls need to be in place to prevent unauthorised access to this persistent storage.
4.27. T3-POL-GUI: Graphical Policy Editor
4.27.1. Entry points
Graphical User Interface of the application
4.27.2. [Asset] Information in Configuration File
4.27.2.1. [Threat] Credentials to Policy Repository are Leaked
4.27.2.1.1. [Attack] Attacker Reads Configuration File
4.27.2.1.1.1. [Existing Mitigation] File System Permissions
4.27.2.1.1.2. [Non existing Mitigation] Don't Store Secrets in the Configuration File
4.27.2.1.2. [Attack] Attacker Sniffs Network Communication
4.27.2.1.2.1. [Existing Mitigation] Use SSL/TLS for Communication between PE and Repository
4.27.3. [Asset] Private Signing Key Used to Sign Policies
4.27.3.1. [Threat] Compromise of the signing key
4.27.3.1.1. [Attack] Attacker Gains Access to Machine Running PE and Obtains Signing Key
4.27.3.1.1.1. [Implemented Mitigation] Use a Password Protected Key Store for the Private Key
4.27.3.1.1.2. [Implemented Mitigation] Do Not Store Password in a File
4.28. T3-POL-CNL: Controlled Natural Language Policy Editor
KENT
This is the same application as T3-POL-GUI.
4.29. T3-POL-WIZ: Wizard Policy Editor
KENT
This is the same application as T3-POL-GUI.
4.30. T3-PORT-JBOSS: JBOSS portal framework
UNIKOLD
The JBoss portal is used to display some portlets that embed different applications of TAS3 and its partners. For example it is possible to choose the audit viewer-portlet (TAS3-component) and a business process-portlet (later from a TAS3-associate).
The applications itself run on the server of its provider. The JBoss portal only shows the view on the applications. Later on these portlets will be able to communicate with each other e.G. to exchange authentication information.
The JBoss server and the underlying application stack (apache, tomcat, java) is an open source product.
4.30.1. Entry points
4.30.1.1. [Intended Entry points]
WebGui to access the JBoss portal
ii. Idp to get user authentication
iii. Portlets (to show the information of the external applications)
4.30.1.2. [Internal Entry points]
Shell or root shell (or ssh) for administrative login
ii. Tomcat management interface
iii. JBoss portal management interfaces
4.30.2. [Asset] user data (functional data) and user credentials (non-functional data)
4.30.2.1. [Thread] catch of user data
4.30.2.1.1. [Attack] Man-in-the-Middle-attack
Sniffing and/or modifying the communication between the JBoss portal and the user or other TAS3 components. e.G. catching of passwords or user data.
4.30.2.1.1.1. [existing Mitigation]end-to-end-encryption
End-to-end-encryption of the whole communication between the TAS3-components, the user and the JBoss portal could prevent a Man-in-the-middle-attack.
4.30.2.2. [Threat] Application Stack
To run JBoss or a fedora-repository several additional underlying components are needed. This is e.g. the operating system, ssh, apache, tomcat and the application (Jboss or fedora) itself.
4.30.2.2.1. [Attack] Flaws in the software components itself
Flaws in the software components (e.G. buffer overflow) enable attackers to obtain more rights than they used to have.
4.30.2.2.1.1. [existing Mitigation] Automatically installed updates prevent older versions and flaws
4.30.2.2.2. [Attack ] Misconfiguration
e.G. guestuser with administrative rights
4.30.2.2.2.1. [existing Mitigation] continuous control and tests with security-tools
4.30.2.2.3. [Attack] easy/bad passwords
Easy passwords e.g. "test" or "secure" can be hacked very easily. This can give an attacker the identity and the rights of the user.
4.30.2.2.3.1. [existing Mitigation] use of blacklists and password rules
Blacklists can be used to prevent trivial passwords and strong password rules ensure secure passwords.
4.30.2.2.4. [Attack] careless user management
Careless user management (e.G. expired users are not removed) allow users to have more rights than they should have.
4.30.2.2.4.1. [existing Mitigation] strict and clear rules and processes for TAS3 partners and members
Continuous checks by the administrators and clear and strict processes for internal user management can support the user management. Rules and processes should be part of the legal documents for TAS3 partnership / member - registration.
4.30.2.3. [Threat] compromised other TAS3-components
4.30.2.3.1. [Attack] compromised idp
A compromised idp could concede wrong data and additional rights to an user.
4.30.2.3.1.1. [existing Mitigation] ensure Trustworthiness
Idps and other security-relevant components and partners have to be trustworthy and controlled internally and regularly
4.30.2.3.2. [Attack] toxic portlets
Portlets could contain unwanted functionality (e.G. additional user request for user id and password that is locally stored --> password phishing) that could allow a Misuse of data.
4.30.2.3.2.1. [existing Mitigation] mandatory previous checks
Portlets should to be checked mandatory before used in the context of TAS3. Also changes made to the portlets should be notified automatically.
4.30.2.3.3. [Attack] DOS-attack
Due to Denial-of-Service-attacks a user could be ‘redirected' to specific and perhaps modified servers and service providers.
4.30.2.3.3.1. [existing Mitigation] Continuous monitoring of availability, continuous checks of log files
4.30.3. [Asset] internal data (non-functional data)
4.30.3.1. [Thread] catch of internal data
4.30.3.1.1. [Attack] Man-in-the-Middle-attack
Sniffing and/or modifying the communication between the JBoss portal and the adminstrators or other TAS3 components. e.G. catching of passwords or user data.
4.30.3.1.1.1. [existing Mitigation]end-to-end-encryption
End-to-end-encryption of the whole communication between the TAS3-components, the user and the JBoss portal could prevent a Man-inthe-middle-attack.
4.30.3.2. [Threat] Application Stack
To run JBoss or a fedora-repository several additional underlying components are needed. This is e.g. the operating system, ssh, apache, tomcat, and the application (Jboss/fedora) itself.
4.30.3.2.1. [Attack] Flaws in the software components itself
Flaws in the software components (e.G. buffer overflow) enable attackers to obtain more access the server at system level..
4.30.3.2.1.1. [existing Mitigation] Automatically installed updates prevent older versions and flaws
4.30.3.2.2. [Attack ] Misconfiguration
e.G. guestuser with administrative rights
4.30.3.2.2.1. [existing Mitigation] continuous control and tests with security-tools
4.30.3.2.3. [Attack] easy/bad passwords
Easy passwords e.G. "test" or "secure" can be hacked very easily. This can give an attacker the identity and the rights of the user.
4.30.3.2.3.1. [existing Mitigation] use of blacklists and password rules
Blacklists can be used to prevent trivial passwords and strong password rules ensure secure passwords. This should be fixed especially for administrators.
4.30.3.2.4. [Attack] careless user management
Careless user management (e.G. expired users are not removed) allow users/admins to access the system even if they should not be allowed any more..
4.30.3.2.4.1. [existing Mitigation] strict and clear rules and processes for TAS3 partners and members
Continuous checks by the administrators and clear and strict processes for internal user management can support the user management. Rules and processes should be part of the legal documents for TAS3 partnership / member - registration. Especially when a admin is leaving the account has to be closed and the system should be checked for backdoors.
4.30.3.3. [Threat] compromised other TAS3-components
4.30.3.3.1. [Attack] compromised idp
A compromised idp could concede wrong data and additional rights to an user.
4.30.3.3.1.1. [existing Mitigation] ensure Trustworthiness
Idps and other security-relevant components and partners have to be trustworthy and controlled internally and regularly.
4.30.3.3.2. [Attack] toxic portlets
Portlets could have access to internal data and pass that to an external receiver.
4.30.3.3.2.1. [existing Mitigation] mandatory previous checks
Portlets should to be checked mandatory before used in the context of TAS3. Also changes made to the portlets should be notified automatically.
4.30.3.3.3. [Attack] DOS-attack
Due to Denial-of-Service-attacks a user could be "redirected" to specific and perhaps modified servers and service providers.
4.30.3.3.3.1. [existing Mitigation] Continuous monitoring of availability, continuous checks of log files
4.31. T3-REP-FEDORA: TAS3 reference repository
UNIKOLD
The Fedora repository is used as a reference repository. It stores user specific data and retrieves it upon confirmed and authorized (service) requests.
The repository itself runs on the server of its provider. The fedora repository and the underlying application stack (apache, tomcat, java) is an open source product. It is enriched by separately programmed modules for TAS3.
4.31.1. Entry points
4.31.1.1. [Intended Entry points]
iv. web service interface to access the repository data
4.31.1.2. [Internal Entry points]
Shell or root shell (or ssh) for administrative login
ii. Tomcat management interface
iii. fedora repository management interface
iv. Idp to get user authentication
PDP to verify the authorization
4.31.2. [Asset] user data (functional data) and credentials (non-functional data)
4.31.2.1. [Thread] catch of user data
4.31.2.1.1. [Attack] Man-in-the-Middle-attack
Sniffing and/or modifying the communication between the fedora-server and other TAS3 components. e.G. catching of credentials or user data.
4.31.2.1.1.1. [existing Mitigation]end-to-end-encryption
End-to-end-encryption of the whole communication between the TAS3-components, the user and the fedora-repository could prevent a Man-in-the-middle-attack.
4.31.2.2. [Threat] Application Stack
To run a fedora-repository several additional underlying components are needed. This is e.g. the operating system, ssh, apache, tomcat, java, dbxml, database and the application (Jboss or fedora) itself.
4.31.2.2.1. [Attack] Flaws in the software components itself
Flaws in the software components (e.G. buffer overflow) enable attackers to obtain more rights than they used to have.
4.31.2.2.1.1. [existing Mitigation] Automatically installed updates prevent older versions and flaws
4.31.2.2.2. [Attack ] Misconfiguration
e.G. guestuser with administrative rights
4.31.2.2.2.1. [existing Mitigation] continuous control and checks with security-tools
4.31.2.3. [Threat] compromised other TAS3-components
4.31.2.3.1. [Attack] compromised PDP
A compromised PDP could concede wrong requests.
4.31.2.3.1.1. [existing Mitigation] ensure Trustworthiness
PDPs and other security-relevant components and partners have to be trustworthy and controlled internally and regularly
4.31.2.3.2. [Attack] DOS-attack
Due to Denial-of-Service-attacks a valid request could be blocked before it reaches the repository or the answer of the repository could be blocked.
4.31.2.3.2.1. [existing Mitigation] Continuous monitoring of availability, continuous checks of log files
4.31.3. [Asset] internal data (non-functional data)
4.31.3.1. [Thread] catch of internal data
4.31.3.1.1. [Attack] Man-in-the-Middle-attack
Sniffing and/or modifying the communication between the Fedora repository and the adminstrators or other TAS3 components. e.G. catching of passwords or user data could be a security problem.
4.31.3.1.1.1. [existing Mitigation]end-to-end-encryption
End-to-end-encryption of the whole communication between the TAS3-components, the user and the Fedora repository could prevent a Man-inthe-middle-attack.
4.31.3.2. [Threat] Application Stack
To run a fedora-repository several additional underlying components are needed. This is e.g. the operating system, ssh, apache, tomcat, java, dbxml, a database and the fedora repository application itself.
4.31.3.2.1. [Attack] Flaws in the software components itself
Flaws in the software components (e.G. buffer overflow) enable attackers to obtain access the server at system level..
4.31.3.2.1.1. [existing Mitigation] Automatically installed updates prevent older versions and flaws
4.31.3.2.2. [Attack ] Misconfiguration
e.G. guestuser with administrative rights
4.31.3.2.2.1. [existing Mitigation] continuous control and tests with security-tools
4.31.3.2.3. [Attack] easy/bad passwords
Easy passwords e.G. "test" or "secure" can be hacked very easily. This can give an attacker the identity and the rights of the user.
4.31.3.2.3.1. [existing Mitigation] use of blacklists and password rules
Blacklists can be used to prevent trivial passwords and strong password rules ensure secure passwords. This should be fixed especially for administrators.
4.31.3.2.4. [Attack] careless user management
Careless user management (e.G. expired users are not removed) allow users/admins to access the system even if they should not be allowed any more..
4.31.3.2.4.1. [existing Mitigation] strict and clear rules and processes for TAS3 partners and members
Continuous checks by the administrators and clear and strict processes for internal user management can support the user management. Rules and processes should be part of the legal documents for TAS3 partnership / member - registration. Especially when a admin is leaving the account has to be closed and the system should be checked for backdoors.
4.31.3.3. [Threat] compromised other TAS3-components
4.31.3.3.1. [Attack] DOS-attack
Due to Denial-of-Service-attacks a user could be "redirected" to specific and perhaps modified servers and service providers.
4.31.3.3.1.1. [existing Mitigation] Continuous monitoring of availability, continuous checks of log files
4.32. T3-REP-JFEDORA: JFEDORA Library for TAS3 Generic Data Format
UNIKOLD
4.32.1. Entry points
i. Java (JAR) library interface
4.32.2. [Assets] : Message based on Generic Data Format
4.32.2.1. [Threat]: Exploitation of messages
4.32.2.1.1. [Attack]: Attackers exploit an application without leaving a trace
4.32.2.1.1.1. [Existing Mitigation]: Identify malicious behavior.
4.32.2.1.2. [Attack]: Attackers cover their tracks
4.32.2.1.2.1. [Existing Mitigation]: Audit and log activity through all of the application tiers.
4.32.2.1.2.2. [Existing Mitigation]: Secure access to log files
4.33. T3-SG-BASE: SOA Gateway Base System
RISARIS
4.33.1. Entry points
Internal Entry point: HTTP PUT/DELETE Method for specific files in configuration directory
ii. Internal Entry point: Shell login to machine for administration
iii. Intended Entry point: A SOAP web service call via the T3-SG-WSP component
4.33.2. [Asset] Backend Legacy data
4.33.2.1. [Threat] SOA Gateway not available
4.33.2.1.1. [Attack] DOS Attack
4.33.2.1.1.1. [Existing Mitigation] Monitoring and Logging mechanisms
4.33.2.1.1.2. [Existing Mitigation] Firewalls utilization
4.33.2.1.1.3. [Implemented Mitigation] Reject requests not validated by T3-SG-WSP component.
4.33.2.2. [Threat] Unauthorized Access to the SOA Gateway services
4.33.2.2.1. [Attack] Read/update data using SOA Gateway services
4.33.2.2.1.1. [Existing Mitigation] Require use of HTTPS
4.33.2.2.1.2. [Implemented Mitigation] Reject requests not validated by T3-SG-WSP component.
4.33.2.2.1.3. [Implemented Mitigation] Ensure TAS3 security is always enabled on the SOA Gateway.
4.33.3. [Asset] Server Configuration Files
4.33.3.1. [Threat] Gain SSH access to machine
4.33.3.1.1. [Attack] Once SSH access is granted, the attacker has access to sensitive data.
4.33.3.1.1.1. [Mitigation Implemented] Ensure credentials are secure. Use SSH public/private key exchange.
4.34. T3-SG-WSP: SOA Gateway Web Service Provider
RISARIS
4.34.1. Entry points
Intended Entry Point: SOAP Web services with TAS3 Security
ii. Internal Entry point: IdP to get user authentication.
iii. Internal Entry point: PDP to verify authorization
4.34.2. [Asset] Web services hosted by T3-SG- WSP component
4.34.2.1. [Threat] Read/update using SOAP Web services
4.34.2.1.1. [Attack] Use the existing web services to read or update existing sensitive data.
4.34.2.1.1.1. [Implemented Mitigation] Ensure TAS3 security is always enabled on the SOA Gateway.
4.34.2.1.1.2. [Implemented Mitigation] Ensure that requests that do not pass the validation are rejected, and the access attempt logged.
4.34.2.2. [Threat] Request/Response Modification
4.34.2.2.1. [Attack] Parameter Tampering, Man in the Middle
4.34.2.2.1.1. [Mitigation Implemented] Request/response encoding using ZXID.
4.34.2.3. [Threat] Unauthorized Access to the SOA Gateway services
4.34.2.3.1. [Attack] Read/update data using SOA Gateway services
4.34.2.3.1.1. [Implemented Mitigation] Reject requests not validated by ZXID AZ API component.
4.34.2.3.1.2. [Implemented Mitigation] Enforce authorization based on the PDP response.
4.35. T3-SP-CVT: Europass CV Transcoding Web Service
EIFFEL
4.35.1. Entry Points
4.35.1.1. Intended entry points
SOAP Back office Web services without TAS3 Security
4.35.1.2. Internal entry points
Authentication key (password) to secure the requesting service.
4.35.2. Asset
Backend temporary personal data storage (optional, used for some transformation which needs to send back a link to a file instead of the CV data itself)
Service/server configuration files
4.35.2.1. Threat
Denial of service
ii. Access to sensitive data in storage
iii. XML injection using Web services, XML
4.35.2.2. Attack
Use the existing web services for :
XML Injection Attack
ii. Buffer Overflow Attack.
4.35.2.2.1. Not existing Mitigation
Validate incoming XML using the corresponding XML Schemas (valid for XML transformation based on Europass Cedefop XML schemas, Hr-XML Schemas, IMS ePortfolio (NL) schemas but not for Leap2a or hResume (i.e. Linkedin) transformations.
4.35.2.3. Attack
Use the existing web services for :
iii. Denial of Service Attack
4.35.2.3.1. Not existing Mitigation
Be sure that optional support of requesting service ID is enabled (which provide a first basic level of security). Update the internal code to replace service ID support by a more secure service authentication token.
4.36. T3-SP-MATCHER: Job Profile Matching Service
NOT
4.36.1. Entry points
Intended Entry point: Web service interface for invoking service
4.36.2. [Asset] Program logic that matches profiles of individuals to opportunities
4.36.2.1. [Threat] Unauthorised invocation
4.36.2.1.1. [Attack]: Unauthorised call to WS interface
4.36.2.1.1.1. [Not Implemented Mitigation]
In order to call the matcher a valid token will be needed. The token issued will come from the main TAS3 authorisation infrastructure and present the correct credentials to the service.
4.36.2.2. [Threat] Overload of service creating failure in audit notifications
4.36.2.2.1. Attack: Denial of service
4.36.2.2.1.1. [ Implemented Mitigation]
To prevent a denial of service attack calling services will be limited to specific to those which have been pre-authenticated by the TAS³ infrastructure. Specific terms of behaviour will govern these services and the matcher will be monitored to detect if a service making calls is in breach of these, for example if it is exhibiting behaviour that can be deemed as a denial of service attack. In this case the offending service will be reported to the appropriate TAS³ authority and blacklisted from calling the matcher.
4.37. T3-STACK and T3-SSO-ZXID
SYMLABS
4.37.1. . Entry points
Shell or root shell (or ssh) administrative login
TAS3 designed management interfaces (none yet)
Product specific management interfaces
Auto-CoT (fully automatic metadata exchange and trust establishment with anonymous third party SPs)
Web GUI
SOAP web service
SLO
WSP
4.37.2. Data assets
Private keys of the service itself
Circle-of-Trust database
Service specific user data stores
Session cache, including EPRs
4.37.3. Nonfunctional assets
Privacy preserving through avoidance of correlation handles
User consent and control of data release
Organizational control of data release
User choice of WSP
Nonrepudiation
Accountability
Credible authentication of system entities
4.37.4. Attacks and mitigation
Too numerous to describe exhaustively in one afternoon *** TBD
Generally the data assets are protected using Unix filesystem permissions against shell and local Unix process access. This, of course, is of little value against root. Therefore deployment MUST use nonroot users for running all TAS3 related processes as well as for most administrative tasks.
The TAS3 designed and product specific management interfaces follow good coding practises (e.g. check for ".." in path) to only allow designed access to the data assets.
Web GUI is coded such that only authorized accesses are possible
SOAP web service is coded such that only authorized accesses are possible
Appropriate crypto layer (such as TLS) is applied in Web GUI, SOAP, and ssh entry points
4.38. T3-TPN-TB2: Trust Negotiation Module
KUL
4.38.1. Entry points
Credentials and Policy Negotiation (CPN) is a web service that can be called upon by any authorised TAS3 infrastructure component.
4.38.2. Assets
The user's attribute credentials and release policies.
4.38.3. Threat
Exposure of the user's attributes credentials and release policies without the user's consent.
4.38.4. Attack
The user's attribute credentials are not exposed without his consent because the CPN agent enforces the user's release policies. Preventing unauthorised exposure is the very essence of the CPN agent functionality.
However, administrative action at the CPN server's site can also lead to unauthorised exposure. This is not prevented by technical means but should be ensured at the CPN agent's site by implementation of physical security coupled with appropriate personnel processes.
4.39. T3-TRU-CTM: Credential based trust service Component
TUE
4.39.1. Entry points
Internal Entry point: Shell or root shell
ii. Intended Entry point: CTM web service Interfaces
iii. Intended Entry point: Credentials Repository Interfaces
4.39.2.1. [Threat] Credentials Disclosure/Modification
Credentials are sensitive information encapsulating roles and attributes referring to the users. For this reasons their disclosure or modification is a threat for the system.
4.39.2.1.1. [Attack] Unauthorized access to the credentials repository
A malicious access to the credentials repository performed by the administrator or an unauthorized user in order to disclose or modify the stored credentials.
4.39.2.1.1.1. [Existing Mitigation]
The use of external monitoring and logging mechanisms to trace and detect suspect activities. These mechanisms should be external to avoid the manipulation of the records performed by malicious administrators.
4.39.2.1.1.2. [Implemented Mitigation]
The usage of an authentication mechanism to prevent the access to the credentials repository performed by unknown or unauthorized agents.
4.39.2.1.2. [Attack] Man in the middle, tampering
A malicious agent gains the access to the credentials intercepting the message exchanged during the querying/updating process involving the credentials repository.
4.39.2.1.2.1. [Implemented Mitigation]
The credentials have a digital signature that makes difficult, for a malicious agent, to fake credentials.
4.39.2.1.2.2. [Existing Mitigation]
The use of secure channels for data transmissions (i.e. HTTPS).
4.39.2.2. [Threat] Unauthorized Access to the CTM service functionalities
The access to the CTM service functionalities itself grants the disclosure of credentials. The response of the service, indeed, brings the credentials.
4.39.2.2.1. [Attack] Brute Force or Password Dictionary
A malicious agent gains the access to the service and obtains the credentials performing a brute force or a password dictionary attack.
4.39.2.2.1.1. [Implemented Mitigation]
Single Sign On (SSO) authorization mechanisms to automatically and safely generate strong and secure tokens.
4.39.2.2.1.2. [Existing Mitigation ]
Mechanisms that press for the usage of strong and effective passwords.
4.39.2.2.1.3. [Mitigation Implemented]
Logging and monitoring mechanisms to detect possible misbehaviours.
4.39.3. [Asset] CTM Web Service
4.39.3.1. [Threat] CTM not available
A malicious agent makes the CTM web service unavailable for the intended users.
4.39.3.1.1. [Attack] Denial of Service (DOS) Attack
A malicious agent or a collectiveness of malicious agents saturates the CTM service with a huge amount of requests.
4.39.3.1.1.1. [Implemented Mitigation]
The existence of monitoring and logging mechanisms to trace suspect behaviours.
4.39.3.1.1.2. [Implemented Mitigation]
The CTM service is not registered in a public register. Only the Trust-PDP has a list of trusted CTM services.
4.39.3.1.1.3. [Existing Mitigation]
The utilization of a firewall for the input output traffic filtering.
4.39.3.2. [Threat] Request/Response Modification
A malicious agent gains the access to the request/response messages exchanged during a CTM service call process in order to modify the results of the service.
4.39.3.2.1. [Attack] Parameter Tampering, Man in the Middle
The request/response messages are modified eavesdropping the network used to exchange the messages.
4.39.3.2.1.1. [Implemented Mitigation]
The credentials have a digital signature that makes difficult, for a malicious agent, to fake credentials.
4.39.3.2.1.2. [Existing Mitigation]
Use of secure channels for data transmissions (i.e. HTTPS)
4.40. T3-TRU-KPI: Key Performance Indicators
SAP
4.40.1. Entry points
Internal Entry point: KPI Data Base
ii. Intended Entry Point: Online sources of KPIs
4.40.2.1. [Threat] Fake sources
4.40.2.1.1. [Attack] a fake host is simulating an online KPI source in order to provide garbage and fake data to the KPI engine
4.40.2.1.1.1. [Existing Mitigation] Authentication mechanism
4.40.2.2. [Threat] KPI values modification
4.40.2.2.1. [Attack] man in the middle attack, interception and modification of the KPI messages sent by the KPI sources to the KPI engine
4.40.2.2.1.1. [Existing Mitigation] Securing the communication channel (SSL, TLS)
4.40.2.2.1.2. [Existing Mitigation] Signing the content of the messages
4.40.2.3. [Threat] Privacy leaks
4.40.2.3.1. [Attack] Sniffing the traffic in order to guess the business objectives of a user or a company.
4.40.2.3.1.1. [Existing Mitigation] Securing the communication channel (SSL, TLS)
4.41. T3-TRU-RTM: Reputation Trust Management Service
TUE
4.41.1. Entry points
Intended Entry point: Shell or root shell
ii. Intended Entry point: RTM web service Interfaces for Trust PPD
iii. Intended Entry point: RTM web service Interfaces for the Feedback Service
iv. Intended Entry point: RTM web service Interfaces for feedback submitting
Internal Entry point: Feedback Repository Interfaces
4.41.2.1. [Threat] Feedback Disclosure/Modification
Feedbacks are sensitive information because a user would like to feel free to release negative feedback without the counterpart knew about that. For these reason the disclosure or the modification of feedback represents a threat for the system.
4.41.2.1.1. [Attack] Unauthorized Access to the feedback repository
A malicious access to the feedback repository performed by the administrator or an unauthorized user in order to disclose or modify the stored feedback.
4.41.2.1.1.1. [Implemented Mitigation]
The usage of an authentication mechanism to prevent the access to the feedback repository performed by unknown or unauthorized agents.
4.41.2.1.1.2. [Existing Mitigation]
The use of external monitoring and logging mechanisms to trace and detect suspect activities. These mechanisms should be external to avoid the manipulation of feedback performed by malicious administrators.
4.41.2.1.2. [Attack] Man in the Middle, tampering
A malicious agent gains the access to the feedback intercepting the message exchanged during the querying/updating process involving the feedback repository.
4.41.2.1.2.1. [Existing Mitigation]
Use of secure channels for data transmissions (i.e. HTTPS)
4.41.3. [Asset] RTM Web Service
4.41.3.1. [Threat] RTM not available
A malicious agent makes the RTM web service unavailable for the intended users.
4.41.3.1.1. [Attack] Denial of Service (DOS) Attack
A malicious agent or a collectiveness of malicious agents saturates the RTM service with a huge amount of requests.
4.41.3.1.1.1. [Implemented Mitigation]
The existence of monitoring and logging mechanisms to trace suspect behaviours.
4.41.3.1.1.2. [Implemented Mitigation]
The RTM service is not registered in a public register. Only the Trust-PDP has a list of trusted RTM services.
4.41.3.1.1.3. [Existing Mitigation]
The utilization of a firewall for the input output traffic filtering.
4.41.3.2. [Threat] Unauthorized Access to the RTM functionalities
The access to the RTM service functionalities can reveal the reputation of an agent.
4.41.3.2.1. [Attack] Brute Force or Password Dictionary
A malicious agent gains the access to the service and obtains the credentials performing a brute force or a password dictionary attack.
4.41.3.2.1.1. [Implemented Mitigation]
Single Sign On (SSO) authorization mechanisms to automatically and safely generate strong and secure tokens.
4.41.3.2.1.2. [Existing Mitigation ]
Mechanisms that press for the usage of strong and effective passwords.
4.41.3.2.1.3. [Implemented Mitigation]
Logging and monitoring mechanisms to detect possible misbehaviours.
4.41.3.3. [Threat] Request/Response Modification
A malicious agent modifies the request or the response changing the reputation values for malevolent purposes.
4.41.3.3.1. [Attack] Parameter Tampering, Man in the Middle
The request/response messages are modified eavesdropping the network used to exchange the messages.
4.41.3.3.1.1. [Existing Mitigation]
Use of secure channels for data transmissions (i.e. HTTPS)
4.42. T3-ZXID-LINUX-X86: ZXID library and tools for TAS3 in apache, Java, PHP, and C (importance,
SYMLABS
4.43. T3-ZXID-SRC: Sources for the ZXID package
SYMLABS