TAS3 is chartered with one overarching business requirement: "secure". For us to meet this requirement, we need to understand the threats. We discuss here various business, IT, operational, protocol, and crypto threats so that we can meet these challenges in our architecture.
Disclaimer: This document has not been reviewed or approved by European Comission.
Contributors
Michele Bezzi, SAP
Jeroen Hoppenbrouwers, Synergetics
Gang Zhao, STARLab, VUB
This document should be read along side of TAS3 architecture documents. It is a requirement that secure architecture addresses all known threats. Therefore this document effectively specifies security related requirements (other more business oriented requirements are discussed in other documents) for the architecture.
Once architecture documents stabilize, the intent is to reference here the specific parts that solve these threats.
Our goal is to answer all threats specified in [NIST-SP800-30]. For programmers [Meier09] provides a good check list and [Meier08] a short list for those in a hurry. Further threats in [NIST-SP800-42] are addressed as well.
This section addresses Reqs. D1.2-2.7-Safe and D1.2-2.8-Avail. Also Req. D1.2-2.9-Correct is touched from secure programming perspective.
Identity Theft
Illegal transactions
Over-privileged process and service accounts.
Untrustworthy Third Party.
Business process modelling flaws. How to audit or validate the model?
Accidental deletion of process steps such as authorization or validation
Dynamically adaptive business process gone wild
Insertion of illegitimate members in trust network.
Moles in trust network. A previously trusted member turns into rougue. How to detect? How to rectify?
Pollution of reputation of other party
Illicit augmentation of reputation by party itself
Defacing Front End web site can cause damage to reputation of the Front End. Defacing attacks can happen through same means as phising (T111-Phish) and also through break-ins, either through network, or physical.
Insertion of wrong CAs into a trust network
Wrongly assigning source of authority to an attribute authority
Wrong assertion of LOA value by an IDP
Replay attack. See CR211-Uniq.
Unencrypted links e.g. SSLnull cipher suites.
Unauthenticated links
Returning grant instead of deny leading to unauthorised access
Returning deny instead of grant leaving to DOS.
Returning wrong obligations
Missing obligations from authz decisions
Attribution of wrong access rights to an otherwise trusted member
Same term meaning different things to two parties leads to illicit access, due to wrong rule inadvertently matching.
Exposure of data due to network sniffing or eavesdropping. Counter measure: encrypt data and manage keys right.
Exposure of data due to database files or transaction logs. Counter measure: encrypt data and manage keys right.
Modification of data in transit. Counter measuers: signing or verification of a hash over the data.
Modification of data in database.
Error condition or exception reveals too much data or system details (usually to aid debugging). Exception output that appears in user interface or over the network is especially damning. Leakage to logs is also a threat.
Error condition or exception causes a core dump that reveals too much data or system details (usually to aid debugging).
Eavesdropping on backups (see CR213-Backup)
Database correlation by colluding entities (solution: do not leak correlation handles, i.e. use pseudonyms - see Architecture, Core Security Architecture, Access Credentials, Pull Model)
IdP collects traffic analysis (and then sells or illicitly use it). Some counter measures:
TN wide data retention policy, audit this: add compliance requirement
Pure play IdP operator vs. mixed functions
Centralized IdP well managed may be a good idea
Disco collects traffic analysis (and then sells or illicitly use it)
Traffic Analysis by Third Party
Correlation handles of audit trail will also become correlation handles.
If WSC parties keeps log of User's pseudonym along with encrypted form of User's identifier at WSP, then WSC and WSP can correlate and collude using the encrypted form. However this threat is acute only between directly interacting parties. In a chain of web services calls longer than 3, the nonneiboughring parties are not in position to collude using this attack.
Current solution is to forbid logging the tokens, see CR53-DontLogTok.
Tricking user to reveal PII through phising attack that poses a real looking web page to solicit PII. See also access version of the threat: T111-Phish.
Social Engineering, talking users to revealing PII. See also access version of the threat: T112-SocEng.
Network eavesdropping to record PII.
Keyboard logger or other malware to record credentials.
PII theft, e.g. copy private contact book, using malware.
Physical theft of PII.
Tricking user to reveal his authentication credentials through phising attack that poses a real looking web page to solicit user's access credentials. This could be created through
DNS manipulation
Cross site scripting
Inappropriate insertion of content in legitimate site
Containment of legitimate site in illegitimate frame
See also PII version of threat: T108-PhishPII.
Social Engineering, talking users to revealing access credentials.
See also PII version of threat: T109-SocEngPII.
Network eavesdropping to record credentials.
Keyboard logger or other malware to record credentials.
Credential theft, e.g. copy private key, using malware.
Physical credential theft.
Dictionary attack on password
Brute force attacks of simply trying out all credentials.
Cookie replay attack. Use previously recorded cookie in context where authentication did not happen. Also arises if expired session cookie is allowed as a factor in authentication, resulting stronger factor not being demanded.
Luring users to do stupid things like
Visit web sites that phish or contain malware
Install malware and troians
Voluntarily give out credentials or PII
Users giving away their credentials to others
Users losing their credentials
Users not protecting their credentials properly e.g. posting passwords on post-it stickers
Authentication delegation models in which the delegate assumes the user's original ID instead of using their own (e.g. as in Shibboleth see https://spaces.internet2.edu/display/ShibuPortal/Solution+Proposal)
Repudiation of events by any party (system entity or user).
Alteration of signed message (see CR27-Sig and CR28-Vfy)
Alteration of audit trail (see CR212-Trail)
Eavesdropping on logs (see CR212-Trail)
Insufficient auditing in the first place
Buffer overflow attack, to gain injection and execution of code, usually leading to compromise of the machine. Also heap overflow.
SQL Query Injection attack, causing database engine to execute unauthorized database statements. This threat also covers similar attacks on other databases or downstream services like shell scripts (command injection).
Access control, signature verification, or other security feature not implemented. Testing only positive cases can easily ignore this type of threat. It is imperative that the test suites also include negative testing.
Input MUST at all times be validated to conform to the expected syntax, and input in general should never be trusted unless there is a cryptographical or structural guarantee of trustworthiness. Some particular perils
Explicit inputs
Environment variables
URL and query string
CGI form fields
Cookies
HTTP headers
SOAP headers
Processing contexts of all sorts passed between software modules
Fields of certificates (from untrusted source, but you would not know until you manipulated the certificate to find out if it is trusted).
Metadata
Messages from event bus
Data coming from database (even if database is supposed to be trusted, it may have been compromised, thus checking for proper format will help to detect the breach and contain it).
Deserialization of any data. This is particularly acute whan using eval to deserialize JSON data.
Perl(1) tainted feature provides a way to track untrusted user input. All untrusted input MUST be scrutinized for attack vectors, such as directory climbing (".." or "~" = home directory) as a path component. Where relative path is expected, an absolute path - one starting by "/" - MUST NOT be allowed. All shell(1) or SQL escape characters (see also T152-Inject) are of highest suspicion until proven to be secure.
When validating input, preferred strategy is to test if input is good and anything that does not pass is bad. The alternative strategy of looking for known bad things (like ".." in path) is much weaker and prone to errors.
Code MUST NOT
Dereference a Null Pointer
Use Freed Memory
Doubly Free Memory
Format string mismatch. In printf(3) format string it is easy to get the format specifiers and actual arguments mixed, resulting inappropriate format specifier being used for a given piece of data.
Truncation of value. Sometimes truncated value can have different meaning.
Signed conversion of a value that may not have been identified.
Reliance on client side validation is no good for server as an alternate client will not perform the validation. Server MUST at all times perform all security critical validations. Client side validation has value in (i) improving user experience and feedback, (ii) reducing network traffic by not submitting obviously invalid inputs, (iii) protecting client side processing like AJAX applications. Such applications MUST be suspicious of what is sent to them by server, in particular if they use JSON and plan to use eval() for processing it.
Cross Site Scripting.
Stack overflow. Similar to T151-Overflow, but specifically applied to the argument and call stack of most compiled programs.
Using non-validated input in the HTML output stream. This could lead into insertion of JavaScript on the generated page.
Improper Pointer Subtraction
Assignment (=) instead of comparison (==).
The cloud operator may gain excessive knowledge about the operation of the network as a whole, or even individual users, if too many Trust Netowork components and Service Providers are colocated with the same cloud operator.
The Cloud operator may be able to see data of several Service Providers and correlate this data.
The Cloud operator may be able to see all of the audit data and correlate it.
Denial of Service by massive network load.
Poisoning DNS or taking DNS down will prevent legitimate players from communicating with each other.
Using program flaw or exception to trigger excessive resource consumption (spinning process, writing all logs full, and leaking memory) or to cause a service to crash.
Feeding service request pattern (e.g. monotonically increasing input size so that previously freed memory is never enough to satisfy the new request) that causes fragmentation of memory, excessive or ineffective garbage collects, or memory leaks.
SPOFs and fat targets: discovery, idmapper, IdP
tas3-threats-v02.pdf
repo.tas3.eu:/var/lib/tas3repo/arch/tas3-threats.pd (1.16)
export CVSROOT=:ext:repo.tas3.eu:/var/lib/tas3repo
cvs co arch
cd arch
# modify tas3-*.pd
cvs ci -m 'What changed...'
~
Please comment on the TAS3WP02@LISTSERV.CC.KULEUVEN.AC.BE mailing list, or that failing, send your comments to the editor.
Any footnotes in this document will not appear in final version. They are editorial comments that may help reviewers to put material in context.