Software Security - Revision history

212.202.0.152 at 16:14, 5 July 2005

2005-07-05T16:14:03Z

← Older revision		Revision as of 16:14, 5 July 2005
Line 1:		Line 1:
			<i>"By security I mean that systems remain depend-able in the face of malice, error or mischance." -- Ross Anderson in "System Security for Cyborgs"</i>

	=Introduction and Terms=		=Introduction and Terms=

141.20.192.175 at 08:19, 21 June 2005

2005-06-21T08:19:57Z

← Older revision		Revision as of 08:19, 21 June 2005
Line 21:		Line 21:
	It has shown quite a few times that subtle implementational mistakes can seriously undermine even the best security design. The most popular of these bugs is probably the infamous [[Buffer Overflow]]. [[Buffer Overflow]]s are now relatively well studied, that is, it is relatively well known how to find, exploit or avoid them. (Which does not mean they are extinct. Far from it.)		It has shown quite a few times that subtle implementational mistakes can seriously undermine even the best security design. The most popular of these bugs is probably the infamous [[Buffer Overflow]]. [[Buffer Overflow]]s are now relatively well studied, that is, it is relatively well known how to find, exploit or avoid them. (Which does not mean they are extinct. Far from it.)
	But there are other, more subtle errors. See the [[Taxonomy of Vulnerabilities]]. Some of these more subtle errors are not even due to uncautious or untrained developers but due to side effects that occur when abstractional layers are traversed in the implementation process. Although training developers for secure coding goes a long way		But there are other, more subtle errors. See the [[Taxonomy of Vulnerabilities]]. Some of these more subtle errors are not even due to uncautious or untrained developers but due to side effects that occur when abstractional layers are traversed in the implementation process. Although training developers for secure coding goes a long way
	towards secure software, we believe it is not possible for a developer to write completely vulnerability-free software. And if this should - against our belief - be ~~true~~, it will most likely not be true in 2, 5, 10 years. This is because the complexity of computer and software systems increases, and growing complexity makes it ever harder to oversee all potential side effects in software, to oversee all interactions between software components. It is along boundaries that security vulnerabilities occur: component boundaries, abstractional boundaries, architectural boundaries, organizational boundaries.		towards secure software, we believe it is not possible for a developer to write completely vulnerability-free software. And if this should - against our belief - be possible today, it will most likely not be true in 2, 5, 10 years. This is because the complexity of computer and software systems increases, and growing complexity makes it ever harder to oversee all potential side effects in software, to oversee all interactions between software components. It is along boundaries that security vulnerabilities occur: component boundaries, abstractional boundaries, architectural boundaries, organizational boundaries.
	Although Software Security has been around for quite some time, no good solution to this problem exists as yet. The methods and procedures to ensure software security are still very archaic, and involve a lot of manual work. Most of this manual work can only be done by highly skilled (and thus rather expensive) experts.		Although Software Security has been around for quite some time, no good solution to this problem exists as yet. The methods and procedures to ensure software security are still very archaic, and involve a lot of manual work. Most of this manual work can only be done by highly skilled (and thus rather expensive) experts.

141.20.192.175 at 08:18, 21 June 2005

2005-06-21T08:18:37Z

← Older revision		Revision as of 08:18, 21 June 2005
Line 1:		Line 1:
	=Introduction and Terms=		=Introduction and Terms=

			Software Security is one aspect of Security Engineering.
	~~Software security~~ is sometimes viewed as a concept separate from software reliability. (Note that the separation between dependability and reliability is not consistently clear in the literature; the two terms are sometimes used interchangeably. We use the term reliability in the sense defined below).		It is sometimes viewed as a concept separate from software reliability. (Note that the separation between dependability and reliability is not consistently clear in the literature; the two terms are sometimes used interchangeably. We use the term reliability in the sense defined below).
	However, it might be more appropriate to consider software security as an aspect of software dependability. After all, the reliability of a system can be defined as		However, it might be more appropriate to consider software security as an aspect of software dependability. After all, the reliability of a system can be defined as
	"the quality of the delivered service such that reliance can justifiably be placed on this service." (see [http://www.informatik.hu-berlin.de/rok/zs/data/slides/zs02_04Concepts.pdf], slide number 14, although Malek uses the term dependability there).		"the quality of the delivered service such that reliance can justifiably be placed on this service." (see [http://www.informatik.hu-berlin.de/rok/zs/data/slides/zs02_04Concepts.pdf], slide number 14, although Malek uses the term dependability there).
Line 11:		Line 12:
	* Testing for Security		* Testing for Security

	~~The~~ ~~term Security Engineering includes both of these activities. They~~ should always be used together. Design for Security includes activities like design audits.		These two should always be used together. Design for Security includes activities like design audits.
	In the past it has shown that there's a third important aspect within Security Engineering that should not be underestimated: Implementation security. This is largely independent from Design for Security, but related to Testing for Security in that Testing for Security aims at uncovering security issues that arise from a systems's implementation.		In the past it has shown that there's a third important aspect within Security Engineering that should not be underestimated: Implementation security. This is largely independent from Design for Security, but related to Testing for Security in that Testing for Security aims at uncovering security issues that arise from a systems's implementation.

			=Design for Security=

			=Implementation Security=

			It has shown quite a few times that subtle implementational mistakes can seriously undermine even the best security design. The most popular of these bugs is probably the infamous [[Buffer Overflow]]. [[Buffer Overflow]]s are now relatively well studied, that is, it is relatively well known how to find, exploit or avoid them. (Which does not mean they are extinct. Far from it.)
			But there are other, more subtle errors. See the [[Taxonomy of Vulnerabilities]]. Some of these more subtle errors are not even due to uncautious or untrained developers but due to side effects that occur when abstractional layers are traversed in the implementation process. Although training developers for secure coding goes a long way
			towards secure software, we believe it is not possible for a developer to write completely vulnerability-free software. And if this should - against our belief - be true, it will most likely not be true in 2, 5, 10 years. This is because the complexity of computer and software systems increases, and growing complexity makes it ever harder to oversee all potential side effects in software, to oversee all interactions between software components. It is along boundaries that security vulnerabilities occur: component boundaries, abstractional boundaries, architectural boundaries, organizational boundaries.
			Although Software Security has been around for quite some time, no good solution to this problem exists as yet. The methods and procedures to ensure software security are still very archaic, and involve a lot of manual work. Most of this manual work can only be done by highly skilled (and thus rather expensive) experts.

			=Testing for Security=

212.202.0.197 at 15:09, 18 June 2005

2005-06-18T15:09:09Z

New page

=Introduction and Terms=

Software security is sometimes viewed as a concept separate from software reliability. (Note that the separation between dependability and reliability is not consistently clear in the literature; the two terms are sometimes used interchangeably. We use the term reliability in the sense defined below).
However, it might be more appropriate to consider software security as an aspect of software dependability. After all, the reliability of a system can be defined as
"the quality of the delivered service such that reliance can justifiably be placed on this service." (see [http://www.informatik.hu-berlin.de/rok/zs/data/slides/zs02_04Concepts.pdf], slide number 14, although Malek uses the term dependability there).
Related to that notion, software security is sometimes viewed as software fault-tolerance under very harsh conditions: The software needs to be tolerant not only towards accidental and random faults but also towards maliciously injected faults and tampering, thus towards faults provoked with malicious intent.
However, even if you like to view software security and software reliability as separate issues, they are always related. In the majority of cases, improving a software's security will also improve its reliability.
There are two main approaches to software security.

* Design for Security
* Testing for Security

The term Security Engineering includes both of these activities. They should always be used together. Design for Security includes activities like design audits.
In the past it has shown that there's a third important aspect within Security Engineering that should not be underestimated: Implementation security. This is largely independent from Design for Security, but related to Testing for Security in that Testing for Security aims at uncovering security issues that arise from a systems's implementation.