What makes software insecure?
Software is often insecure because it is complex, abstract and not completely understood even by the people who create it. A software specialist who designs a human interaction module may not know much about the database software that the module depends on, for example.
In addition, software runs in a hardware environment (the computer system) that is not completely known by the creator of the software. For example, when a software package is designed to run in a Microsoft Windows system, the hardware may have been manufactured by any of a dozen companies, each of which has its own detailed hardware environment (including things like BIOS, memory, storage, and input/output subsystems).
And the software itself has to keep changing to keep up with user expectations. Software that doesn’t get updated gets stale. [See more about this in my previous blog: stable or static]:
What vulnerabilities are there in software?
Software is vulnerable to many possible conditions that it may not be prepared for. For example, unexpected inputs can lead to errors: if the software is expecting a number and it gets a value that is outside of reasonable bounds, it may have unpredictable consequences.
In addition, computer hardware can have exception conditions occur during instruction execution, such as dividing by zero. These exceptions must be anticipated by the software, or else the program can simply terminate without finishing its work.
For example, one of the popular ways for hackers to break into computer systems is to create a “buffer overflow condition.” If the software does not anticipate this condition, the computer can execute code that the hacker put into a data structure in advance, causing the computer to come under the control of the hacker.
Why are they always discovering new holes & vulnerabilities in our software and systems? Doesn’t testing take care of these problems?
Proper testing can reduce insecurities and other bugs. Often, software development organizations simply don’t use the best tools for testing. But testing every possible case is impossible. Testing has to be done using human judgment to decide the testing strategy.
[For an excellent exposition on this subject, see Gerald Weinberg’s book, Perfect Software]Often the failure to do adequate testing is the fault of management. When a software development project is behind schedule, the temptation to short-change the testing is very high, because testing is usually tacked on to the end of the development cycle.
[For more on this, see my previous blog: good software]How else is software insecure?
Most software does not run in a vacuum. Often it is interacting with a human operator. When a program and a human are interacting, there are plenty of opportunities for misunderstandings. For example, error messages may be confusing, or the human may take the wrong action in response to a warning message.
The people who make it their business to take advantage of software vulnerabilities – call them hackers or attackers – are becoming more sophisticated. They may be after money or industrial secrets, and they often know a lot about the system and the person who is interacting with the system.
A whole class of attack, called spear-phishing, is based on deliberately showing misleading information to the human, such as an email that appears to come from the person’s boss. Vulnerability to these attacks occurs both in the system (email delivery without validation) and in the person (accepting what appears at face value).
What’s an enterprise to do about insecure software?
As a first step, make sure that you have engaged security specialists – people who have studied and are expert in attacks and in security countermeasures. The specialists should include “white hat” testers – people who deliberately try to break into your own systems in order to demonstrate vulnerabilities.
You should also ask questions of your project managers about tradeoffs being made between testing and quality. You must recognize that when you choose to emphasize schedule, you often invite lower quality and therefore higher vulnerability.
Never assume that software is of high quality – and therefore invulnerable – until you have seen it demonstrated in actual use by real users. And even then, expect to find vulnerabilities regularly, and be ready to fix them.
TO SUBSCRIBE FREE: https://johnlevyconsulting.com/blog
Just complete the simple form. Takes about 10 seconds. And you’ll also get a free copy of my report, “9 Mistakes That Lead to IT Project Failure.”
John Levy — Turn Around IT Helping business get full value from IT
https://johnlevyconsulting.com
PO Box 1419, Point Reyes Station, CA 94956 415 663-1818
About John Levy