version 1.14, 1998/02/19 22:26:58 |
version 1.15, 1998/02/19 22:37:51 |
|
|
available extremely quickly. |
available extremely quickly. |
|
|
<p> |
<p> |
|
|
Our security auditing team typically has between six and twelve |
Our security auditing team typically has between six and twelve |
members, and most of us continually search for and fix security holes. |
members, and most of us continually search for and fix new security |
We have been auditing for approximately two years. The process we |
holes. We have been auditing since the summer of 1997. The process we |
followed to increase security was simply a comprehensive file-by-file |
followed to increase security was simply a comprehensive file-by-file |
analysis of every critical software component. Flaws were found in |
analysis of every critical software component. Flaws were found in |
just about every area of the system. Entire new classes of security |
just about every area of the system. Entire new classes of security |
problems were found while we were doing the audit, and in many cases |
problems were found while we were doing the audit, and in many cases |
source code which had been audited earlier had to be re-audited with |
source code which had been audited earlier had to be re-audited with |
these new flaws in mind. |
these new flaws in mind. |
|
|
|
<p> |
|
Our security auditing proces is a proactive one. In almost all cases |
|
we have found that exploitability is not an issue. We have fixed many |
|
simple and obvious careless programming errors in code and then only |
|
months later discovered that the problems were in fact exploitable. |
|
The proactive auditing process has really paid off. Statements like |
|
``This problem was fixed in OpenBSD about 6 months ago'' have become |
|
commonplace in security forums like BUGTRAQ. |
|
|
<p> |
<p> |
The auditing process is not over yet, and as you can see we continue |
The auditing process is not over yet, and as you can see we continue |