Ted Demopoulos    Demopoulos Associates
keynote speeches
Security, IT, Business Consulting
securITy newsletter
Articles

Ted Demopoulos’ securITy
___________________________________________________________

The free newsletter of Demopoulos Associates, www.demop.com

We NEVER rent, sell, or share email addresses.

Please forward this newsletter to anyone you know who might enjoy it!

  • Our new blog “The Ted Rap” is now available at www.demop.com/thetedrap, containing Ted’s comments on IT, Security, Business and more. It’s a less formal outlet for information than this newsletter, and Ted promises not to ramble too much. Recent posts include “Operating Systems need to be Secure by Default,” The Offshore Threat, is it real?” and “Killer Apps, Killer Benefits.”
     

  • Slides and links to relevant papers from Ted’s recent keynote for the Defense Contract Management Agency now online at www.demop.com/DCMA.html.

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.

Prototype code can be compromised as well and often ends up incorporated into production applications. Test code can also be compromised. As much as possible, prototype and test code need to be well written and secure. Of course it would be naive to state that prototype and test code can always receive the same amount of attention to detail as production code and can always be as well written, but they should certainly not be “garbage code.”

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.”

Of course it’s easy to preach when in the pulpit, and harder when in the foxhole. Management, customers, and others might be screaming for the latest release. In extreme cases getting a software release out soon, any release, might determine whether the company still exists in a few weeks or not . . .

Bad code goes hand in hand with increased bugs, security problems, and long term expenses.  In the long term, good code pays.

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.

For example, how much risk and which risks are acceptable in protecting the entire customer database which may include credit card and other sensitive information? This is NOT a decision that IT should make alone! It is a risk management decision that requires input from upper level management.

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 appropriate security later is difficult if not impossible because the design may be fundamentally insecure. Adding security can also cause changes to features and/or application interfaces affecting backwards compatibility.

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.

Security test plans are critical. Just haphazardly “testing things,” while not entirely useless, is very far from ideal. The Test Plan, including security testing, should be an integral part of the systems development.

Testing is NOT a replacement for good design and implementation. It can discover vulnerabilities, but cannot prove that no vulnerabilities exist.

___________________________________________________________

The free newsletter of Demopoulos Associates, www.demop.com

This newsletter is Copyright © 2004 by Demopoulos Associates, Durham, New Hampshire, USA.  All rights are reserved, except that it may be freely redistributed if unmodified.

Sharing securITy is encouraged if the copyright and attribution are included.

Subscribe to the securITy newsletter

Name
Email

We NEVER rent, sell, or share email addresses.

Please forward this newsletter to anyone you know who  might enjoy it!

 

© Copyright 2002-2015, Demopoulos Associates