Coupon Accepted Successfully!


Penetrate and Patch

Often software is developed in an “Internet time” highly compressed schedule in order to be first to market. This approach considers security as an add-on feature after delivery. When vulnerabilities are found, frequently as a result of an attack, patches are developed and issued to the user community. There are many problems with this “penetrate-and-patch” approach to security. Here are a few:
  •  “Developers can only patch problems which they know about. Attackers may find problems that they never report to developers.
  •  Patches are rushed out as a result of market pressures on vendors, and often introduce new problems of their own to a system.
  • Patches often only fix the symptom of a problem, and do nothing to address the underlying cause.
  • Patches often go unapplied, because system administrators tend to be overworked and often do not wish to make changes to a system that “works [7]”. It should also be noted that system administrators are often not security experts.


Build Security into the Software Development Life Cycle


The recommended approach is to incorporate software security as an engineering goal  throughout the software engineering life cycle. Since many of the issues of software security are issues of risk management, the spiral model of software development is often mentioned as appropriate, with the repetitive spiral refining and converging security considerations toward the final goal.  Some activities that should be added to each life cycle stage are listed below.    

  • Requirements: Add security specifications.
  • Design: Develop threat models by viewing the system form an adversary’s perspective and apply security design principles, e.g. “Design with the Enemy in Mind”
  • Implementation:  Add secure coding standards and language subsets
  • Testing: Add Security test plans and use random input testing (e.g. Fuzz Testing) or vulnerability analysis using penetration testing.

Principles for Software Security

It has been said that 90% of security problems can be avoided if the following principles are followed [7]:


1.  Secure the weakest link: security is a chain

2.  Practice defense in depth: manage risk with diverse defensive strategies

3.  Fail securely: Failures are unavoidable and should be planned for

4.  Follow the principle of least privilege: minimum access required to perform an operation and only for the minimum time necessary

5.  Compartmentalize: minimize the amount of potential damage by organizing the system into the smallest number of units as possible.

6.  Keep it simple

7.  Promote privacy

8.  Remember that hiding secrets is inherently difficult

9.  Be reluctant to trust: Servers should be designed to distrust clients and conversely.

10. Use your community resources: Use security libraries and cryptographic algorithms that have been widely used and evaluated


Some Important Specific Software Security Issues


Language Selection

Many factors influence the choice of a programming language to use for implementation. It is common for efficiency considerations to dominate the language selection process. One of the factors should be security considerations. For example, choosing the C programming language for efficiency should take into account the inherent security risks associated with a language that has no bounds checks on array and pointer references. The programmer must build these checks into the program code. C program efficiencies and low-level data manipulation capabilities come at the high risk of security vulnerabilities and very special diligence is required.  Using a language like Java can greatly reduce these risks, since it performs bounds checking.  However, the system requirements must tolerate a lower level of run-time performance for this to be a viable option.


Buffer Overflows

Buffer overflows as a security vulnerability have been discussed for 40 years and yet this type of software problem continues to be one of the most frequently reported instances of system attacks. A buffer overflow is a condition caused by a write operation into a fixed-sized buffer in which the size of the data is larger than the size of the buffer. Most buffer overflows are the result of the properties of the C language mentioned in the last section above. This is the case with C++ as well.


Test Your Skills Now!
Take a Quiz now
Reviewer Name