Additional Requirements for the SaaS Reputation Service
The following list of requirements focuses on the different, cloud aspects of this architecture. Earlier chapters covered in some depth other aspects, such as endpoint requirements, web requirements, and administrative needs.
- • The calculation processor will not read from the reputation cache. A message will be sent from the calculation processor to the cache to execute a delete of all references to an object in the cache. Failure of the deletion will be logged. No acknowledgment will be returned by the cache in response to the deletion message.
- • Reputation request messages must be constructed by the web front end. Only the queried object will be passed to the calculation processor.
- • The front end will sanitize and validate messages from the mobile device. Any message that fails validation in form or data must be rejected.
- • Before reputation requests will be received, a device certificate, signed by the private key of the reputation service, must be validated by the reputation front end. Certificate validation failure must cease all further communications.
- • All customer reputation requests and request histories will be encapsulated with an unpredictable token. The token will be related to a cryptographic hash. The hash is the only value to be associated to service tenants. The hash-to-client relationship must be kept in a separate network segment, under separate administrative control (different team) from the application administrative team and from the storage and data administrators. Hash-to-token correlation will be done by a separate process running in the back-end, unexposed to any processing outside the internal back-end networks. Wherever stored, tenant reputation histories will be tagged with the token only. No mention of customer identity can be placed within that administrative domain or network segment.
- • Reputation data will be pushed from the data farm on the internal network to each reputation data instance.
- • Reputation data instances will exist on a segregated network that only receives requests from the reputation calculation and processing module.
- • There will be four distinct layers, as shown in Figure 11.2:
a. The DMZ, bastion layer containing the web service termination. Authentication of device certificates will take place before a reputation request may be made.
b. A front end module that validates requests before any processing may occur. Requests will be regenerated before they are passed on to subsequent layers. Objects about which a reputation query is made may only be passed from the front end after careful validation and format check. The reputation cache is placed in this segment. It receives requests only from the front end.
c. The reputation calculator/processor, which only receives reformed requests from the front end.
d. The local reputation instance for a point of presence, which will only receive requests for data from the calculation module.
- • The front end request processing input must pass rigorous fuzz testing before release.
- • The calculation module’s request handling processing chain must pass rigorous fuzz testing before release.
- • An HSM will be employed at each node to perform certificate, message, and data- signing operations. Multiple private keys, including customer specific keys, must be supported. Every node must validate every device certificate.*
1. Mell, P. and Grance, T. (2011). he NIST Definition of Cloud Computing, NIST Special Publication 800-145, Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology, Gaithersburg. Retrieved from http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf.