Posts Tagged ‘vulnerabilities
Software is a central and critical aspect of the computer (and embedded system) security problem. Software defects with security ramifications —including implementation bugs such as buffer overflows and design flaws such as inconsistent error handling — promise to be with us for years. All too often, malicious intruders can hack into systems by exploiting software defects. Moreover, Internet-enabled software applications present the most common security risk encountered today, with software’s ever expanding complexity and extensibility adding further fuel to the fire.
Software security’s best practices leverage good software engineering practice and involve thinking about security early in the software design life cycle (SDLC), knowing and understanding common threats (including language-based flaws and pitfalls), designing for security, and subjecting all software artifacts to thorough objective risk analyses and testing.
Security is an emergent property of a software system. This is a subtle point often lost on development people who tend to focus on functionality. Obviously, there are security functions in the world, and most modern software includes security features, but adding features such as SSL (for cryptographically protecting communications) does not present a complete solution to the security problem. A security problem is more likely to arise because of a problem in a standard part of the system (e.g., the API to the server) than in some given security feature. This is an important reason why software security must be part of a full lifecycle approach. Just as you cannot test quality into a piece of software, you can not spray paint security features onto a design and expect it to become secure.
Figure 1: Software security best practices applied to various software artifacts in the Software Design Life Cycle (SDLC)
As practitioners become aware of software security’s importance, they are increasingly adopting and evolving a set of best practices to address the problem. There is no substitute for working software security as deeply into the development process as possible and taking advantage of the engineering lessons software practitioners have learned over the years. Figure 1 specifies one set of best practices and shows how software practitioners can apply them to the various software artifacts produced during software development. Although the artifacts are shown laid out in a linear sequence, most organizations follow an iterative approach, which means that best practices will be cycled through more than once as the software evolves.
Software security best practices apply at various levels:
- The requirements level: Security requirements must cover both overt functional security (e.g., the use of applied cryptography) and emergent characteristics.
- The design and architecture level: A system must be coherent and present a unified security architecture that takes into account security principles (such as the principle of least privilege).
- The code level: Static analysis tools — tools that scan source code for common vulnerabilities — can discover implementation bugs at the code level.
Risks crop up during all stages of the software life cycle, so a constant risk analysis thread, with recurring risk tracking and monitoring activities, is highly recommended. Security testing must encompass two strategies: testing security functionality with standard functional testing techniques, and risk-based security testing based on attack patterns and threat models. Penetration testing is also useful, especially if an architectural risk analysis is specifically driving the tests.
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”.