Worst Practices in Developing Secure Software, Part I
As I’ve said before, The “Best Practices Mantra” annoys me.
A major component of success involves avoiding making any major mistakes. Instead of focusing exclusively on implementing “Best Practices,” I suggest avoiding “Worst Practices.” You can do almost everything perfectly, but if you do one thing horribly wrong you can negate everything. A soldier greatly increases his chances in a firefight by doing things right, but one serious mistake and his odds of surviving plummet. Fatal flaws and mistakes are often exactly that – FATAL!
Part I focuses on higher level issues while part II will focus on lower level issues. Part II will be coming in February.
Assuming that only “important” software needs to be secure.
All programs and services need to be secure. Even a simple game or utility could be compromised, contain a Trojan or otherwise harbor malicious code, and lead to your entire network being compromised.
Emphasizing hitting deadlines ahead of writing “Good Code.”
Deadlines are important, but not at the expense of writing decent code! Can you image an engineering project in the physical world taking the equivalent attitude? “That bridge will open August 1st no matter what. We’ll let the bridge users uncover any unresolved problems and patch them later.”
Having IT make all risk management decisions.
Every business decision involves risk. Many important IT decisions are important business decisions and can involve significant risk. Some IT decisions involve enough risk that executive management should be involved in the decision making process.
Not considering security during the entire application lifecycle.
Security should be considered during the entire application lifecycle. Security must be part of the system design based on the product security goals, attention must be paid to security during implementation, and operational issues including installation are critical as well.
Adding security is more time consuming and resource intensive than doing it “right” from the beginning, hence it is less likely to be done well or given due diligence.
Assuming the software won’t be attacked.
Most software is attacked! Don’t make the following common and usually false assumptions:
–The users are friendly
–Input will not be malicious
–The environment is hospitable
–The firewall will shield the application from hostile users and attacks
Not doing any security testing.
Security testing is *much* different than functional testing and both are important. Instead of examining a system’s response under fairly normal circumstances, security testing involves probing the system looking for weaknesses much like an attacker would.
Condensed from http://www.demop.com/WorstPracticesSecSoftI.htm, which is condensed from the course Application Security Principles.
A major component of success involves avoiding making any major mistakes. Instead of focusing exclusively on implementing “Best Practices,” I suggest avoiding “Worst Practices.” You can do almost everything perfectly, but if you do one thing horribly wrong you can negate everything. A soldier greatly increases his chances in a firefight by doing things right, but one serious mistake and his odds of surviving plummet. Fatal flaws and mistakes are often exactly that – FATAL!
Part I focuses on higher level issues while part II will focus on lower level issues. Part II will be coming in February.
Assuming that only “important” software needs to be secure.
All programs and services need to be secure. Even a simple game or utility could be compromised, contain a Trojan or otherwise harbor malicious code, and lead to your entire network being compromised.
Emphasizing hitting deadlines ahead of writing “Good Code.”
Deadlines are important, but not at the expense of writing decent code! Can you image an engineering project in the physical world taking the equivalent attitude? “That bridge will open August 1st no matter what. We’ll let the bridge users uncover any unresolved problems and patch them later.”
Having IT make all risk management decisions.
Every business decision involves risk. Many important IT decisions are important business decisions and can involve significant risk. Some IT decisions involve enough risk that executive management should be involved in the decision making process.
Not considering security during the entire application lifecycle.
Security should be considered during the entire application lifecycle. Security must be part of the system design based on the product security goals, attention must be paid to security during implementation, and operational issues including installation are critical as well.
Adding security is more time consuming and resource intensive than doing it “right” from the beginning, hence it is less likely to be done well or given due diligence.
Assuming the software won’t be attacked.
Most software is attacked! Don’t make the following common and usually false assumptions:
–The users are friendly
–Input will not be malicious
–The environment is hospitable
–The firewall will shield the application from hostile users and attacks
Not doing any security testing.
Security testing is *much* different than functional testing and both are important. Instead of examining a system’s response under fairly normal circumstances, security testing involves probing the system looking for weaknesses much like an attacker would.
Condensed from http://www.demop.com/WorstPracticesSecSoftI.htm, which is condensed from the course Application Security Principles.
posted by Ted Demopoulos at 12:34 AM
Comments on "Worst Practices in Developing Secure Software, Part I "
post a comment