Talk:Application Security Architecture Cheat Sheet

I noticed some thing are missing here - taking a page from OWASP SAMM. Any application architecture must always begin with requirements. I have found requirements to come from the following sources:

- Laws
- Standards 
- Business Policies 
- Customers
- Operations 
- Business Stakeholders
- Project Stakeholders

All of these governance issues inform the rest of the architecture - in other words it is cross-cutting. Layers in the architecture cake are:

- Business View (Context)
- Architect View (Concept)
- Designers View (Logical)
- Builders View (Physical)
- Trade View (Component)
- Facilities View (Operational)

Suggested Changes/Additions

As we gear up to get this sheet out of Draft mode, hopefully by end of year, I have a few comments. I have not suggested these edits directly on the page yet as I welcome preliminary discussion:

Overall Comments

I really like the organization and layout of this particular Cheat Sheet. It's extensive, but that's appropriate to the overarching topic at hand.

I do wonder, though, if we should provide examples at certain points. I have found in the past that doing so on application developer checklists/cheat-sheets can help trigger a thought in the reader's mind. By way of example, take this point: "What mechanisms are used to share data with third‐parties besides the application itself?"

It could prove useful to provide examples -- rather than risk a reader glossing over it a bit or misunderstanding the intent. So perhaps that could be modified to this: "What mechanisms are used to share data with third‐parties besides the application itself? (EDI transmissions, FTP file processing, vendor-exposed API's, etc.)"

I'm interested in folks' opinions on this. The risk with including examples is that examples are not (by nature) all-inclusive. But if our target for this includes a wide range of developers and managers, examples could help spur internal team discussion.

Specific Section Edits and Suggestions for Additions

Under Business Requirements, I believe that an additional point is warranted under Regulations: "How will changes to regulatory requirements be communicated, managed and implemented over time?"

Under Infrastucture | Virtualization and Externalization, I would modify this point: "What aspects of the product may or may not be hosted via the cloud computing model?" ... to include a reference to the distinction between "pure" cloud services like AWS and Managed Hosting Cloud Services that allow greater control over administration etc. So perhaps this: "What aspects of the product may or may not be hosted via the cloud computing model? If applicable, what approach(es) to cloud computing will be taken (Managed Hosting versus "Pure" Cloud, a 'full machine' approach such as AWS-EC2 versus a 'hosted database' approach such as AWS-RDS and Azure, etc)? How will the advantages and constraints of each model be weighed and decided upon?"

Under Application Requirements | Environment I would add an additional point: "How will database connection strings, encryption keys, and other sensitive components be stored, accessed, and protected from unauthorized detection?"

Under Application Requirements | Data Processing I would modify the following: "What encryption requirements have been defined for data in transit over WAN and LAN links?" ...to include public access via http or https (technically I guess this could be considered WAN but I think making it more clear would be helpful). So, perhaps the following: "What encryption requirements have been defined for data in transit - including transmission over WAN, LAN, SecureFTP, or publicly accessible protocols such as http: and https:?"

Under Application Requirements | Application Monitoring, I would modify the following: "What application error handling and logging requirements have been defined?" ...to specify that sensitive information should be kept away from unauthorized eyes. So maybe this: "What application error handling and logging requirements have been defined? What processes are in place to show an end user only the minimum required information upon an error, and not to expose facets of application design, security, and implementation?"

- VM