-The Thinking Person's Guide to the Cloud. HOWTO: Keep your head in the clouds and your feet on the ground (by Gunnar Peterson, Arctec Group).
-Threat modeling (by John Steven, Cigital).
Especially the presentation of Gunnar Peterson was magnificent. He was funny, to the point and also explained the basic stuff, so you didn't have to be an expert to understand everything. He especially explained that a general mistake often made by non-security people, is to think that SSL secures your entire application. SSL is great, but there is a lot more to think about than just this one aspect.
There are a lot of methodologies to make your security vulnerabilities visible. This is called 'Threat modeling'. A simple and common used methodology is 'STRIDE', which stands for Spoofing, Tampering, Repudiation,Information Disclosure, Denial of Service and Elevation of privilege. These are the things you want to counter. The following table gives possible security solutions targeted at each specific problem.
Spoofing - Authentication
Tampering - Digital Signature
Repudiation - Audit Logging
Information Disclosure - Encryption
Denial of Service - Availability
Elevation of privilege - Authorization,Input validation
For each of the 6 items we have 3 categories where we could implement a security solution. You can implement it on the data level, method level and channel level. An example of the different levels:
• Data: XML
• Method: SOAP, URI
• Channel: HTTP
This means that you have 18 possibilities for implementing security. SSL however only is a solution for information disclosure, because you encryt the data on the channel level. Mostly that's not enough and you should for example encrypt parts of the xml message too.
SSL alone is not enough to secure your application!
Nice post!
ReplyDeleteHowever I do not fully understand the diagram.
It states that SSL/TLS is only applicable for information disclosure (I). You also say:
"SSL however only is a solution for information disclosure"
I do agree that applying "STRIDE" on different levels has its own (extended) advantages.
For example, when adding an XML DSig, you make the integrity, confidentiality and authenticity part of the XML message it self. This also implies you can guarantee non-repudiation later on (if stored somewhere).
With SSL/TLS you don't have that since these elements are long gone after extracting the payload.
However, although the primary function of SSL/TLS is confidentiality (by encryption) it DOES provide integrity of the transmitted message.
It does that by adding a MAC to the payload, which is also encrypted together with it.
So when you receive a SSL/TLS payload, you are sure it contents remained confidential, but also unchanged (integrity).
Further more, the authentificty of an SSL message can also be enforced by using client authentication (also called mutual SSL authenticatin). Upon receival of the message the client can be authenticated
As stated above, the scope is limited to the channel, but on that level SSL should afaik be "STI" and not only "I".
Is there anything that I'm missing why that is not indicated as such on the diagram?
Koen,
ReplyDeleteNice comment.
First of all it's the diagram of Gunnar Peterson, I don't want to take credit for the slide and can only give you my interpretation. This post serves as a summary of his talk because I liked it so much.
Seconde of all, I think you misunderstand the diagram. It only mentions SSL, not TLS. The goal of Gunnar was to emphasize that merely having a reverse proxy and a server certificate - aka basic SSL- alone cannot prevent me as a user from pretending to be someone else. If I go to https://fortisbanking.be they also need security on the application level (logging in via my bankcard and pin) to assure that I really am Philip Nollet. I don't have a client certificate and the app doesn't use my MAC address to validate anything. That's why SSL is no solution against Man in the middle attacks.
In the case of TLS or mutual SSL you would have been right since there you also have the client certificate.
I'm not an expert regarding the 'tampering', but can't tools like Mallory, Webscarab or Burp, ... tamper with SSL data?
Koen,
ReplyDeleteI double checked something and I made a little mistake regarding TLS, but my main train of thought remains correct.
TLS is just a standardized version of SSL apparently. In the RFC is says: 'TLS protocol itself is based on the SSL 3.0 protocol specification as published by Netscape'. You can setup TLS to have one way or to have mutual authentication.
Standard it's one way, and I think that Gunnar meant that in that way it doesn't offer much protection.