Friday, April 06, 2007
Explaining Security to the Business Community...
How do you effectively explain security to the business community?
Have you ever asked yourself why aren't corporations doing a better job of protecting information? Is it because they don't understand? Well, yes but that doesn't address the entire problem space. As an IT professional, you may have already observed that business analysts and even business architects do a pretty good job of capturing functional requirements but a pretty lousy job of capturing requirements around system qualities.
Maybe, those who understand security need to stop talking about IT constructs such as OpenID, XACML or even the need for secure coding practices and start talking about how security fails at the weakest point. Often security or the lack of is a human factor, not an algorithm or specification. The simplest security is involves the metaphor of creating an inside and outside within a system one wishes to secure.
Of course in some ways we have abused the notion of the word perimeter in that we have used analogies such as DMZ. In the military, the DMZ is the unguarded region that neither party aims to protect. I suspect that if you were to go into any corporate environment and ask them what is in their DMZ, the analogy falls apart pretty quickly.
Cyberspace has no inherent geometry. Everything is connected to everything else. You can limit the connections but anyone can re-establish a connection anywhere. Compare and contrast this notion with the fact that every vendor and their marketing folks say: Our products are coded to best practices standards of the industry and have been security audited which feels goods but really isn't measurable.
In terms of the actual programming practices, the best thing is to understand the common attacks and basically treat guarding against them as coding and design standards. That really amounts to knowing what classes of messages are risky to send to an object and why.Systems need to be as simple as possible so someone that specializes in breaking systems not building them really can review them quickly and make an informed opinion as to their potential for insecurity.
Security is a business issue, and many decisions should be may by business people. Perhaps it's useful to make a distinction between high-level security requirements and low-level security requirements. A high-level requirement might be something like "It should not be possible to steal other users' credit card numbers without spending $1m." A low-level requirement would be something like "Credit card numbers are stored in an encrypted form in the database." The high-level requirement is something that makes sense to the client; the low-level makes sense to IT folks. We could take this one step further and expect that the business community specify the former but that architects have some latitude once properly educated to specify for themselves the latter.
I would like to ask those in the blogosphere to help me quantify my thinking by asking the very next business customer you run across the following questions:
| | View blog reactionsHave you ever asked yourself why aren't corporations doing a better job of protecting information? Is it because they don't understand? Well, yes but that doesn't address the entire problem space. As an IT professional, you may have already observed that business analysts and even business architects do a pretty good job of capturing functional requirements but a pretty lousy job of capturing requirements around system qualities.
Maybe, those who understand security need to stop talking about IT constructs such as OpenID, XACML or even the need for secure coding practices and start talking about how security fails at the weakest point. Often security or the lack of is a human factor, not an algorithm or specification. The simplest security is involves the metaphor of creating an inside and outside within a system one wishes to secure.
Of course in some ways we have abused the notion of the word perimeter in that we have used analogies such as DMZ. In the military, the DMZ is the unguarded region that neither party aims to protect. I suspect that if you were to go into any corporate environment and ask them what is in their DMZ, the analogy falls apart pretty quickly.
Cyberspace has no inherent geometry. Everything is connected to everything else. You can limit the connections but anyone can re-establish a connection anywhere. Compare and contrast this notion with the fact that every vendor and their marketing folks say: Our products are coded to best practices standards of the industry and have been security audited which feels goods but really isn't measurable.
In terms of the actual programming practices, the best thing is to understand the common attacks and basically treat guarding against them as coding and design standards. That really amounts to knowing what classes of messages are risky to send to an object and why.Systems need to be as simple as possible so someone that specializes in breaking systems not building them really can review them quickly and make an informed opinion as to their potential for insecurity.
Security is a business issue, and many decisions should be may by business people. Perhaps it's useful to make a distinction between high-level security requirements and low-level security requirements. A high-level requirement might be something like "It should not be possible to steal other users' credit card numbers without spending $1m." A low-level requirement would be something like "Credit card numbers are stored in an encrypted form in the database." The high-level requirement is something that makes sense to the client; the low-level makes sense to IT folks. We could take this one step further and expect that the business community specify the former but that architects have some latitude once properly educated to specify for themselves the latter.
I would like to ask those in the blogosphere to help me quantify my thinking by asking the very next business customer you run across the following questions:
- How valuable to you is the data or resource you are protecting? Do you think the amount of money you spend protecting this data is the same as the desires of your customers?
- How valuable would this data be to somebody else? How much do you think they would be willing to invest in order to break your security?
- How much should we invest in training software developers to write secure code to avoid security problems down the road?
- When should IT develop a core competency in secure coding practices vs. simply relying on others outside the enterprise?
