We have been taught in the last 10 years that application security is what is important, that software must be coded securely and that infrastructure was becoming less and less relevant. So why is it then that when I am writing a security view for a recent project, the majority of my web application security threats are mitigated via the infrastructure?
The OWASP top 10 has become a bible for web application security and the Microsoft security frame a very useful checklist. How about if you could defend against all the OWASP top 10 and implement all the controls in the security frame without touching one line of code? That is what we got close to on this project:
All the key controls are implemented in the infrastructure. Developers can be left to coding the functionality and improving performance. The security controls can also be implemented at a company level, with minimal security involvement required per project. Is it just that when all you have is a hammer, everything looks like a nail or is this truly a better approach?
Photo credit: MarcelGermain Flikr
Like this post? Get updates via RSS or follow me on Twitter @rakkhis
The OWASP top 10 has become a bible for web application security and the Microsoft security frame a very useful checklist. How about if you could defend against all the OWASP top 10 and implement all the controls in the security frame without touching one line of code? That is what we got close to on this project:
MS Security Frame Control | OWASP Top 10 threat mitigated | Infrastructure control |
Input validation | A1 - Injection A2 - Cross site scripting | A BIG-IP F5 with a web application firewall and layer 7 IPS modules deployed in front of the presentation servers. As a web application with less than 20 forms and 50 input fields it was simple to write whitelist validation rules for all input. The input was generally alphanumeric only and/or could be tightly validated with a regex. Where input is used in output the WAF provides escaping. A further protocol analysis firewall between the application and database servers validated that no SQL or OS commands were passed even though paramaterised queries are being used, adding defence in depth. |
Authentication | A3 - Broken authentication and session management | All requests to the web application are intercepted by Siteminder as the web application manager (WAM). Site minder provides an authentication screen and validates credentials against an LDAP. Siteminder also calls on the RSA server to provide a step up two factor authentication and can be used to include federated single sign-on in future. |
Authorization | A4 - Direct object references A8 - Failure to restrict URL access A10 - Un-validated redirects and forwards | Siteminder checks the users LDAP group, determines the users role and ID and injects this into every http header as an encrypted and signed token. The application can then use this to determine the functions and information that should be available to the user (note code is required here but the Java Spring framework built-in operator) |
Configuration management | A6 - Security misconfiguration | Secured through authentication and authorization detailed above Hardened builds are used for all infrastructure and Tripwire is used to monitor file integrity and key configuration settings. nCircle is used to scan for vulnerabilities and a patching process exists. |
Protecting sensitive data | A7 - Insecure cryptographic storage A9 - Insufficient transport layer protection | The F5 also establishes the TLS connection and provides SSL offload capability to improve performance. Sensitive data fields are encrypted using the DB2 database encryption. Keys are stored in hardware security module attached to the database server. |
Session management | A3 - Broken authentication and session management A5 - Cross site request forgery | WebSphere application manager manages the session and inserts form tokens to prevent CSRF |
Cryptography | A7 - Insecure cryptographic storage A9 - Insufficient transport layer protection | No custom cryptography is used as it is all performed by the infrastructure. RSA2048, AES256, SHA256 algorithms and key lengths are used. The passwords stored in the LDAP are hashed and salted. |
Exception management | The F5 web application firewall ensures that only a white list of exception data can be output. Stack traces, SQL, credit card numbers etc are not allowed to be output. | |
Auditing and logging | Logging is performed in the web application firewall, Siteminder and Apache. All logs are exported to a central Splunk repository where alerts and correlations are defined for monitoring |
All the key controls are implemented in the infrastructure. Developers can be left to coding the functionality and improving performance. The security controls can also be implemented at a company level, with minimal security involvement required per project. Is it just that when all you have is a hammer, everything looks like a nail or is this truly a better approach?
Photo credit: MarcelGermain Flikr
Like this post? Get updates via RSS or follow me on Twitter @rakkhis
Share this, that's how ideas spread: Tweet
No comments:
Post a Comment