One of the areas security can improve in view is to be less audit-centric ("I am just going through the motions because auditors told me to do this and someone else is paying") and instead be more architecture centric. Architecture means understanding tradeoffs and making making choices on what to build.
Because of the infosec industry's audit-heavy past, we have a lot of laundry lists of things to do. That's how auditors operate. Note, I am not against audit as a function its very valuable, we need checkpoints. But it should be a function, not the only or dominant function. Laundry lists do not shed light on priorities or dependencies or other engineering questions.
Laundry lists tend to be static, they do not map to engineering processes or how to operationalize security. Gary McGraw, Sammy Migues, and Jacob West recently published BSIMM version 6 which some of these critical gaps. BSIMM goes beyond the audit mindset and it highlights key activities and touchpoints that link the activities into a living, breathing organization. These are the activities that help you make security real.
I see three areas where security engineering can be improved in many organizations and they all have their root in capability engineering. The three properties are efficacy, efficiency, and adaptability.
First is efficacy. Its surprising, but most of the least secure systems in any enterprise are security systems themselves. Security people often say (rightly) that complexity is the enemy of security, but yet when we try to solve security problems we introduce things like Kerberos and X.509. There is nothing in your enterprise anywhere that is as complex as X.509 or Kerberos. Its simply taken for granted that if a system is purchased or built for security purposes add security. Security teams are very good at testing apps and systems for vulnerabilities. The same should be done for security mechanisms themselves. In fact, these security mechanisms should be more rigorously tested because they are a foundational element and they are usually reused. Efficacy can be measured in part using threat models.
Making security efficient is challenge. Security teams should ensure that there is an ongoing effort to make security security capabilities - easy to use and cost effective. This has to do with drilling down on any barriers in security processes and optimizing scarce resources. As Fred Brooks said:
The critical thing about the design process is to identify your scarcest resource. Despite what you may think, that very often is not money. For example, in a NASA moon shot, money is abundant but lightness is scarce; every ounce of weight requires tons of material below. On the design of a beach vacation home, the limitation may be your ocean-front footage. You have to make sure your whole team understands what scarce resource you’re optimizing.
The third property is adaptability. Having a capability is not the same as using it and deploying it widely. The width and breadth of adoption is an important metric to use. A significant percent of the security team's effort and resources should be devoted to making sure that the capabilities are drop dead simple to use in applications. The effort here is often on packaging and building interfaces that can offer security capabilities to a broad set of platforms and users.