In a perfect world, ... what is your webappsec “wish list"?

I was recently asked what web application security model/framework I would like to see within the development process that (assuming all requirements were being addressed) would allow me to enjoy a relaxing, albeit hypothetical =), vacation away from broadband access and the constant worries of web application security. =)

I know, I know, this seems like a silly exercise on the surface but bear with me on this one. As I dove into it further, I realized that it was actually quite helpful for fleshing out my concerns and then mapping these concerns back to possible solutions.

I realized that I spend most of my time trying to manage the expectations of others and I had not yet effectively presented my own expectations.

I am also sensing an opportunity to measure progress within the overall web application security effort and possibly map this back to quantifiable and repeatable metrics as well.


Here is an initial cut at my "wish list" (in no particular order and subject to change):

1. No code defects. Period.
a. Effective Static Code Analysis (SCA) tool will help here.
b. Security issues are exponentially less expensive the earlier in the SDLC they are found
c. Processes designed to catch code defects early are consistent with proactive security
d. "Underneath all our security issues lies our inability to write defect-free code. Solve that and we've solved the security issues. Focus on the security alone and we won't solve anything". (Credit to Ivan: http://blog.ivanristic.com/2008/07/ive-come-to-rea.html)

2. All developers are adequately trained and understand how to write secure code
a. Developer incentives for writing secure code
b. Developer incentives for undergoing/completing security training

3. Ongoing incentives for developers to proactively find defects in application code that they are not directly responsible for

4. No XSS in the application
a. Potentially redundant since "no code defects" above implies no XSS

5. No XSRF in the application
a. Again, potentially redundant since "no code defects" above implies no XSRF

6. Web AppSec team involved as early in the feature conception and business case/justification phase as possible

7. Web AppSec team involved within "requirements" phase as well.

8. Web AppSec team involved within user design and feedback phase

9. Web AppSec team involved during clarification of the PRD (including tech specs and tech review)

10. Web AppSec team involved during implementation plan

11. Web AppSec visibility offered within QA process
a. QA process has complete coverage of entire web application
b. QA regression tests are comprehensive and effective

12. The number of ingress/egress points within the web application will be kept to a minimum.
a. Main authentication page cannot be bypassed for direct access to other pages on the site
b. Only one ingress point into the application (login page)

13. No mixed content allowed
a. HTTPS is required for ALL content on the site
b. This includes requirement for "secure" flag on cookies

14. Entry pages to the app will be kept simple.
a. Authentication/gateway access points to the application are control points and these pages should remain simple in order minimize risk for bypassing security.

15. Access to ALL pages in the app will require authentication

16. Support for Current authentication Security Standards.
a. Authentication scalable to accommodate web services

17. Session identifier timeout value is easily and readily adjustable within the range of 0-30 minutes.
a. Preference is for unique session identifier (single use) per user transaction
b. However performance implications of this dynamic session identifier allows the option to readily and easily scale (on demand) session identifier timeout value to as high as 30 minutes when necessary.

18. All user data is required to be encrypted in transit

19. All user data is encrypted "at rest", specifically Personally Identifiable Information (PII)
a. Column level encryption offered for all customers/users

20. No unknown use cases within the web application
a. All possible use cases have been planned for and identified

21. Application offers complete and granular reporting into user actions to assist with forensic analysis

22. All possible user "incidents" have been planned for in terms of security "events" and a pre-determined course of action is available for all events

23. All data is escaped appropriately when rendered back to the user's browser

24. Threat Modeling and Data Flow Diagrams
a. Ongoing Threat Modeling for the entire web application
b. Current Data Flow Diagrams are maintained for the entire web application

25. Defenses against Distributed Denial of Service (DDoS) attacks

26. Defenses against Phishing/Pharming attacks


My apologies for the long post, ... =)

As always, your thoughts/comments are both welcome and encouraged.

thanks,

joe

<<<>>>