Avoiding the Red Queen

Stephen Northcutt posted a nice comment on the SANS webcast I did with Jacob West from Fortify  SANS on SOA, Web Services security

I took a few minutes to watch a Gunnar Peterson video ... His major points are that software is about improving the quality of life and vulnerabilies in software keep us from improving the quality of life. He then correctly reasoned that security people like me will not be able to help him. He feels that developers need to innovate out of this problem. Now, he does overdo the security people depend on firewalls for everything line, but it is deserved to some extent. He also points out that security should be a business enabler, in the same way brakes, seatbelts and other safety features allow you to drive fast and live. 

I overdid the firewalls line?  Whatever could he mean? ;-P  Its true security isn't just network address translation, sometimes we get to enable SSL on some parts of web servers.

By the way, I don't give a fig who solves the software security problem, could be architects, could be developers, could be infosec, mostly likely its a mix, but I do think innovation is required to solve. Some of this is better tools, but a lot of it is integrating capabilities that we already and more a matter of transforming how we build stuff to factor security in.

Education is a big thing here - developers simply don't know enough to build security in and integrate it appropriately. Security people don't know enough about software to 1) select the right contols, 2) locate those controls 3) consult on integrating them into the architecture and 4) verify they  are working. So education and training is essential on both fronts, but hey don't believe me, listen to Charlemagne.

SOA and Web services are a prime example here, people have been building out these technologies that run the core of their business for six plus years, security is starting to get engaged and we are starting to see some  encouraging signs of security getting more baked into SOA and Web services, but the Red Queen says sthere is still a long way to go. 

Comments

[Andre Gironda]

Just because the network is being replaced by VNET and application virtualization, it doesn't mean that people like Stephen or organizations like SANS, with vast experience and wide-swinging power, aren't desperately needed in our new school.

Application security is not replacing network security, it's just a big piece of the overall risk prevention. The failures of SSL and firewall will eventually turn into strengths as we balance the schools of thought. While I agree with you, Gunnar, that we need new kinds of defenses, forensics, and incident handling at every application tier -- I also think that risk comes primarily from the silo-ization, over-specialization, and lack of "seeing the big picture" by everyone in our industry -- at every organization.

The most profound realization that we need to come to terms with is identification of organizational behavior issues, along with the mobility to make organizational change agile and to develop the harmonious cultural ties between appsec, netsec, virtsec, and audit teams that is necessary to address all kinds of risk.

[Gunnar]

Andre - my post is not negative towards Stephen at all or infosec. I think you, he, and I all agree a new approach is needed. And that approach needs to incorporate elements from classic operational IT security that got us to where we are so far plus security higher up the stack like apps, data, and busines concerns. Today the industry remains heavily skewed towards the former, just walk the RSA conference floor.

Wrt, over-specialization. This is an interesting point to consider going forward, but you know DBAs know a lot about Oracle or SQL Server and not too much about J2EE and .Net, yet their databases still seem to work. Infosec whas not mastered specialization much less over specialization at the infostructure - app/data/business level yet. So I don't see overspecialization as a near term risk, but I guess we can aspire to having that problem ;-P

[Alex Hutton]

G-

You need a new row:

2007 Cloud Computing - Network Firewalls, SSL

[Clive Robinson]

I have been saying it for a while but it is worth repeating ;)

"Security" is to ICT what "Quality" is to a physical product manufacturing process.

In the early days of mass production of complex consumer items (electronic radios etc), there where good indications of the difference between good engineering design and bad. The good had low return rates and the bad high return rates.

Due to the asymetric distribution costs, the very significant cost of warranty returns ment that even a few % difference on return rates made the difference between a good profit and a very bad loss.

Unfortunatly the "software industry" does not have the same asymetric distribution cost issue to open their eyes to "design and manufacturing" issues, and by and large we moan and gripe but accept the junk we get from the "software industry".

For mass production it was found that attention to detail and rapid feedback of defects on the production line had a significant and advantageous effect on return rates.

It was clear that attention to detail fed back to the early stages of the deisgn process made major contributions to profit that far out weighed the costs of the processes involved, likewise any defects found in the field. It is one of the main reasons for project "History Files" so that system designers and engineers can "learn" from past mistakes.

The formal "QA process" originated in the UK via BSI standards that later where accepted "as is" to make the ISO9000 range of standards we all (should) know and love ;)

What became obvious from the use of these standards to other parts of a business, is that although not obvious in how they did it, when properly implemented they made a significant improvment to the bottom line, even though the process had attendent costs (call it improved efficiency and reduced waste).

Further it became obvious that organisations that only "did it for accreditation to keep the customers happy" did not see real improvment, but those that bought into it from the top did see real improvment.

Most managers in large organisations accept the fact that Quality although increasing costs increases profits more even though the accountants cannot put their finger on which particular bean does it with their ROI calculations ;)

Currently (although it is changing) "Security" is often seen by managment as "sunk costs" with no "real ROI", or more simply "a waste of resources".

This needs to be changed "Security" as a process needs to be sold as a "Quality" process to managment, and they need to accept like Quality there is no easily identifiable ROI on it.

Part of the problem as to why this adverse situation has occured is most senior managers "Speak Business" and most ICT practicioners "Speak Technical".

As ICT/security practitioners we need to remember that "The Man" who cuts our cheques at the end of the month and decides if we contribute to the bottom line, does not want or need to speak technical.

That is if we wish to communicate effectivly with him we need to learn his language "Bussines Speak" so that we don't put him off to sleep ten seconds after we start talking or worse like "Loud British/American tourists" anoy him to the point of anger by rudley insisting on speaking our own forign language "Technical Speak" in what is his country.

And it needs to be real, not just play acting as it currently is. Which is one of the reasons why we see blog posts and about Security ROI with such choice phrases as, "counting on their fingers" etc.

To reiterate there are two broad issues here that must be resolved before we move forward on the security process,

1, The first is security is an issue that is not just bolted on as an after thought it is a process that needs to be in from the very start just like that of Quality.

2, The second is that the education technical people at junior managment levels most need is "business" not "technical". So that technical issues can be communicated and apraised effectivly.

On the second point I am not saying as others do that the CIO needs an MBA. I am saying it's not just him but all technical people need more than a parsing knowledge of the way a business works and talks. I guess a basic diploma in Business should be a requirment for any level of technical managment including lowly team leaders.

And yes thirdly, accountable "Quality" and "Security" processes must be part of the buying process, otherwise our processess will fail to the GIGO effect no matter how hard we try.

Demand written proof of it from your suppliers and of their suppliers and in turn make it available to your customers. Your suppliers will in turn will pass it back up the line to those that make the products. Don't alow yourself to be fobbed of with marketing bells and whistles and vague promises make it a cast iron condition of the purchase up front in the contract or purchase order.

Quality as a process worked for mass production manufacturing and small businesses when integrated into the work flow it's been proven to work for software development as well.

The Security process is not realy any different from the Quality process we just need to kick start the process along the right lines.