Posts Tagged ‘scope
The specific results of this research will be constrained by certain characteristics of the research methodology. The first of these involves the simulation to be used for testing the routing algorithm. The simulation model will be designed to imitate a given computer network; therefore, results obtained from the simulation will be directly related to that specific network design. This will not prevent any generalized conclusions from being developed since the network dependencies involved are consistent between networks. For example, any type of network will degrade in performance as failures increase. Similarly, an increase incongestion will eventually cause performance degradation no matter what type of network is concerned. Although the results of this research will not guarantee universal results, it will provide results that may easily be generalized to relate to most routing situations.
A second limiting characteristic of the research methodology pertains to the fuzzy sets being utilized in the routing algorithm as they are defined with specific shapes and refer to certain network metrics. The specific metrics and fuzzy set shapes that will be used in this research are not definitive for the algorithm but seem most appropriate in this dissertation. All networks differ in some respect and therefore, current routing algorithms require appropriate parameters to be established when initiating a network. Therefore, the shapes ofthe fuzzy sets and the metrics used in the algorithm can easily be altered to reflect the individual features of the network. These details will be explained explicitly in chapter four.
All of the databases we cover in this volume have had serious security flaws at some point. Oracle has published 69 security alerts on its “critical patch updates and security alerts” page — though some of these alerts relate to alarge number of vulnerabilities, with patch 68 alone accounting for somewhere between 50 and 100 individual bugs. Depending on which repository you search, Microsoft SQL Server and its associated components have been subject to something like 36 serious security issues — though again, some of these patches relate to multiple bugs. According to the ICAT metabase, DB2 has had around 20 published security issues — although the authors of this book have recently worked with IBM to fix a further 13 issues. MySQL has had around 25 issues; Sybase ASE is something of a dark horse with a mere 2 published vulnerabilities. PostgreSQL has had about a dozen. Informix has had about half a dozen, depending on whose count you use.
The problem is that comparing these figures is almost entirely pointless. Different databases receive different levels of scrutiny from security researchers. To date, Microsoft SQL Server and Oracle have probably received the most, which accounts for the large number of issues documented for each of those databases. Some databases have been around for many years, and others are relatively recent. Different databases have different kinds of flaws; some databasesare not vulnerable to whole classes of problems that might plague others. Even defining “database” is problematic. Oracle bundles an entire application environment with its database server, with many samples and prebuilt applications. Should these applications be considered a part of the database? Is Microsoft’s MSDE a different database than SQL Server ? They are certainly used in different ways and have a number of differing components, but they were both subject to the UDP Resolution Service bug that was the basis for the “Slammer” worm.
Even if we were able to determine some weighted metric that accounted forage, stability, scrutiny, scope, and severity of published vulnerabilities, we would still be considering only “patchable” issues, rather than the inherent security features provided by the database. Is it fair to directly compare the comprehensive audit capabilities of Oracle with the rather more limited capabilities of MySQL, for instance? Should a database that supports securable views be considered “more secure” than a database that doesn’t implement that abstraction? By default, PostgreSQL is possibly the most security-aware database available — but you can’t connect to it over the network unless you explicitly enable that functionality. Should we take default configurations into account? The list of criteria is almost endless, and drawing any firm conclusions from it is extremely dangerous.
Ultimately, the more you know about a system, the better you will be able to secure it — up to a limit imposed by the features of that system. It isn’t true tosay, however, that the system with the most features is the most secure because the more functionality a system has, the more target surface there is for an attacker to abuse. The point of this book is to demonstrate the strengths and weaknesses of the various database systems we’re discussing, not — most emphatically not — to determine which is the “most secure”.