The best security program is at the business with the happiest customers.

There's a fine line between happy customers and playing piano in a bordello.

Sees a lot
Can tell the king he has no clothes
Can tell the king he really is ugly
Does not get killed by the king
Nice to have around but…how much security improvement comes from this ?

Changes happened faster that he was able to move
Did not read the signs
Good intentions went unfulfilled
A brutal way to ending a promising career
Sad to have around but…how much security improvement comes from this ?

Obviously these models of CISOs are not solving our information security problems. Instead Dr. Garigue points us to Charlemagne as a better model

King of the Franks and Holy Roman Emperor; conqueror of the Lombards and Saxons (742-814) - reunited much of Europe after the Dark Ages.

He set up other schools, opening them to peasant boys as well as nobles. Charlemagne never stopped studying. He brought an English monk, Alcuin, and other scholars to his court - encouraging the development of a standard script.

He set up money standards to encourage commerce, tried to build a Rhine-Danube canal, and urged better farming methods. He especially worked to spread education and Christianity in every class of people.

He relied on Counts, Margraves and Missi Domini to help him.

Margraves - Guard the frontier districts of the empire. Margraves retained, within their own jurisdictions, the authority of dukes in the feudal arm of the empire.

Missi Domini - Messengers of the King.

This is the way forward! Find software security champions in the architecture and development groups,help them understand the real security issues. They will find solutions you have not thought of. Same for DBAs, same for business analysts even. Its all about beating the bushes, education, and decentralizing security services. Specifically, he points out this important mandate for IT security

Knowledge of risky things is of strategic value

How to know today tomorrow’s unknown ?
How to structure information security processes in an organization so as to identify and address the NEXT categories of risks ?

To me this is our mandate and measure of effectiveness. Empower our customers, educate, and create business value. If I am a CISO  I don't want 20 people reporting to me who do firewall ruleset changes. I want one champion in 20 different groups - development teams, architects, DBAs, business analysts.

A concrete example, infosec can continue to go along with the herd and follow the "what everyone else is doing architecture" meanwhile developers are connecting every single thing in your business to the Web. I have been doing integration and new technology projects for a long time, and let me tell you - Change does not always create happy customers in the short run. But the chart below shows that information security is maybe more concerned with not causing waves rather than adapting.

The best security program is at the business with sustainable competitive advantage.

On 13 August, jcorey asked about how to deal with those who firmly believe that the only answer to any security problem is to inspect everything at the edge. This is an important question, and I wanted to give Joe an answer. (You might have to scroll down when you click the previous link, it seems that linking to individual comments is broken.)

Today, 15 October, I wrote a little thesis as an answer to his question. I’m calling it out in a separate post because I want to make sure those of you with aggregators that don’t update when posts receive new comments still have a chance to reply with your thoughts. I’ll also repost it here:

jcorey-- You've nailed the biggest obstacle to deploying something like direct connect. Many security professionals have been taught that there simply is, and never will be, a process or technology that allows you to trust anything that originates from outside your corpnet. These professionals cling to this belief, and have been the cause that allowed the whole “detection” market to bloom.

Let me be clear: this total lack of trustworthiness is no longer absolutely true. Of course there will be times when unknown machines will be used by known and unknown people to access your information. But what about one particular subset -- known humans, with known portable computers -- can't we do something better than treat them as toxic invaders?

Indeed we can. And that's what I'm proposing with direct connect. The technology -- managed, of course, with the right processes -- exists so that you can extend the trust to known computers even though you don't trust the network they're connected to. This is because you have mechanisms that:

1. Allow you to configure the machine according to your requirements (domain join, group policy)

2. Dictate computer and user authentication requirements (IPsec policies, smart cards)

3. Limit what the users of these machines can do (UAC, non-admin, Forefront Client Security, Windows Firewall, even software restriction policies)

4. Validate the health of machines initiating incoming connections and remediate if necessary (NAP, System Center Configuration Manager)

5. Limit the threat of attacks against stolen computers (domain logon, smart cards, BitLocker with TPM)

With the robust authentication, validation, configuration, and control mechanisms available to you, I simply don't see that there's any need to fall back to “detection” now. Detection technologies were -- and remain -- necessary for the times when we have no clue about the health of client computers and when we had no way to gauge the intent of the users. But it is truly reflective of a head-in-the-sand mentality to assume that this is a complete description of what's capable today.

You know, someone once asked me what it takes to be a security professional. I answered that there are two primary elements: become a networking/packet wonk, and be willing to change your opinions when the right evidence comes along. Indeed, I suspect that many security folk have forgotten the need to keep their wonikness updated, which in turn makes them resist new ideas regardless of the strength of the evidence. I'm not very proud of what I just wrote, because I loathe generalities, but I'm not sure what else to think here. Sigh.

Joe’s question is important and strikes at the foundation of what it means to be a security professional today. I’m eager to continue this conversation, because it’s reflective of what I sense to be a radical shift in our jobs—we are, or should be, no longer the wolf-crying propeller-head who sits in the basement and twiddles with the firewall. Instead, our job should be defined as one who’s charged with protecting the organization’s information from attack, while maximizing its utility to authorized users, according to the principles of least privilege. Your thoughts?

Developers have the objective of building a functional application. They are focused on building more functionality into applications. Moreover, building security creates more workload  for Developers which is a disincentive and moreover, Developers are rewarded for building more functionality than building more security. I have never seen a Developer in my professional life for being rewarded for building a secure application.

Hackers are focused on how to break the application. They look for weak links in application that will enable them to access application data. Developers usually follow process to build application, but Hackers have no process and all they have is multitude of possibilities. Hackers are innovative in trying various permutations in compromising the application.

A million dollar question is whether we can build secure applications when a Developer is focused on functionality but not on breaking the application?

There is a school of thought about Inside-out security where the application is built securely from scratch. Unfortunately,  this approach won't suffice because hackers traverse Outside-in. A little reflection will highlight the importance of vulnerability scanning and penetration testing of application. This will bring the perspective of what developers do not know already.

Building a secure application inside out is not enough. In order to address unknown unknowns (or blind spots of developers), penetration testing should be done. Both whitebox style penetration testing (where components of an application is known)  and also blackbox style penetration testing which mi micks an Hacker who may not have any knowledge of the application, should be carried out.

An application of higher level of security is not built just by Developers. It is built by integrative process of Developer mindset and Hacker mindset.  This is a constant struggle for years to come.