...
| Identifier | Type | Threat | Mitigation |
|---|---|---|---|
| STO_1 | Information Disclosure | Attack on network : For memcached/database (whatever the number of nodes) or Ehcache/JBoss cache (on multinodes), data are transfered between nodes using TCP. These data can be intercepted and scanned to know which TGT is linked to which identity. | Add an entry to the hardening guide to indicate that single node CAS deployments should prefer to use Ehcache since the communication between CAS and Ehcache will be internal to the JVM. Also, disk persistence should preferably turned off to avoid saving the sensitive data to the disk. Add an entry to the hardening guide to indicate that the ehcache/jboss replication or the external database/memcached should either be restricted to a private network, or else run over SSL/TLS to protect the data in transport. When using ehcache, consider using JGroups for communication which has support for encryption. Encryption/hashing scheme:
|
| STO_2 | Information Disclosure | Attack on disk : For database/Ehcache cache storage on disk, an attacker can read the content of the stored files and find the identities and their associated TGT. | Add an entry to the hardening guide to indicate that for single node CAS, disk persistence should preferably turned off to avoid saving the sensitive data to the disk. Add an entry to the hardening guide to indicate that the any disk based memory should either be restricted to a private storage, or else encrypt data on disk. Should we really use Ehcache to store data on disks : not really performant and secure ? For database, some encryption mechanism can be enabled on disk stored data. |
| STO_3 | Information Disclosure | Attack on memory: Various tools can scan the memory of other processes. We should try to do things to protect the data in memory and hash and encrypt data as soon as possible. This may involve interactions with the garbage collector, including removing sensitive data in the clear so that the young garbage collector can handle this sensitive data rather than relying on the full garbage collection to remove this data.
| Use best practices to remove unencrypted, unhashed sensitive data from memory as soon as possible. |
| STO_4 | Spoofing | The attacker can generate false data and send them to the storage system. | Use hash / cryptographic algorithm to prevent attackers from being able to forge keys and store data. |
Threats on CAS interaction with authentication sources (e.g. LDAP or username/password DB)
| Identifier | Type | Threat | Mitigation |
|---|---|---|---|
| STO_1 | Information Disclosure | Attack on network : Username/password can be intercepted in transit These data can be intercepted and scanned to know which TGT is linked to which identity. | Add an entry to the hardening guide to LDAP deployments should prefer to use ldaps + certification validation unless the calls are guaranteed to be traveling over an untrusted network with an internal dns. If a database is being used, recommend to turn on SSL/TLS and certificate validation for the Database endpoint to ensure that the username is not being passed on to an intruder the calls are guaranteed to be traveling over an untrusted network with an internal dns. |
| STO_2 | Information Disclosure | Attack on disk : Attacker could steal the list of username/passwords from an insecure database. | Add an entry to the hardening guide to indicate that for single node CAS, disk persistence should preferably turned off to avoid saving the sensitive data to the disk. Add an entry to the hardening guide to indicate that the any disk based memory should either be restricted to a private storage, or else encrypt data on disk. Should we really use Ehcache to store data on disks : not really performant and secure ? For database, some encryption mechanism can be enabled on disk stored data. |
| STO_3 | Information Disclosure | Attack on memory: Various tools can scan the memory of other processes. We should try to do things to protect the data in memory and hash and encrypt data as soon as possible. This may involve interactions with the garbage collector, including removing sensitive data in the clear so that the young garbage collector can handle this sensitive data rather than relying on the full garbage collection to remove this data.
| Use best practices to remove unencrypted, unhashed sensitive data from memory as soon as possible. |
| STO_4 | Spoofing | The attacker can generate false data and send them to the storage system. | Use hash / cryptographic algorithm to prevent attackers from being able to forge keys and store data. |