Some example of 'the basics' that are often missed:

• Using existing identity repositories. For some reason everyone wants to re-invent a user and access management module within their project. I've run into several situations where even .Net projects can't integrate with Active Directory. A large majority of organisations already have a central user repository (even small ones) and they don't need you to provide another one. Especially, given the time it takes to enforce at least a minimal subset of user and access management rules already in place on the central repository, on the cruddy custom one.
• Not providing for integration with master data sources. Nearly every application in today's organisation will need to integrate with other systems, with very rare exceptions. These should be mapped out and implemented in-line with a SoA or integration strategy, and not the awful DB->flat file->scheduled scripted copy people are so fond of.

There are lots more example of these, but what I really want to focus on is the original point: doing security right, often has positive consequences. What I mean by positive consequences is something that has a measurable ROI, as opposed to the, insurance salesmen - grudge purchase, security is often seen as. For example, if we get the identity integration right as per the first point above, then cost savings on user management occur, as existing processes and resources can be leveraged to perform these tasks, instead of paying for new ones. This is on-top of the benefit (realised either way), of not getting hacked up and down. Orm in the case of the integration point; by providing a re-usable interface, future applications can benefit from the integration work, without having to paying for a new one. Also, on-top of the benefit of maintaining the CIA of the transfer.

My theory from all this is simply: Systems security must be designed at an architectural level, and implemented at a technical level.

If someone came up to me and told me that today, I would be tempted to provide a 'no-duh' response. However, 1.5 years ago, I would've argued that the real security work happens at the technical level and architecture, while necessary, was only an input into security. However, if you look at many organisational structures today, how many of them have security sitting on the architecture forums, or have security involved in the high level architecture definition (apart from our clients ;) )? I would wager very few, even though so many people would smirk at my theory. The oft-seen norm is for security to get involved once the project has been defined, scoped and architected. The worst case of this is when security is only involved at UAT testing.