The innermost cores of DoD systems are the databases. In cyber attacks viruses can be implanted in applications, denial of service can block networks or malicious code can produce false results. In all of such cases there are ways how reconstitution can take place. However, if an adversary degrades a shared database from which applications draw data, recovery is difficult. A petabyte database may contain tens of millions of data elements, which are updated at millisecond speeds. If the database integrity attack is designed to be gradual and progressive the users will be receiving results that only few will question. At a critical point the users will stop trusting their computer screen and resort to other means how to improvise what to do without computer aid.
The greatest threats to DoD cyber operations are not external attacks but the subversion from an insider. Whatever may be the motivation for perverting a major database is immaterial. Whether it is malicious, or from a disgruntled employee or from an enemy operative is irrelevant. What will ultimately matter is that a critical moment an act of cyber warfare will disable warfare operations.
A number of database vendors offer “Database Vault” protection software. The question is whether this offers safeguards in cases where personnel performing data base administration (DBA) tasks are a threat.
When databases are corrupted the greatest risks do not arise from technical failures against which elaborate safeguards are known to exist. In protecting databases the most important question is who is in charge of real-time policing of the actions taken by DBAs? What is the chain of responsibility for real-time countermeasures? What is the role of the auditors and administrators to see to it that adequate safety processes are in place? What are the separate chains of command through which the various actors in ensuring database security report?
The problem of safeguarding databases is compounded by the fact that database software is one of many applications that run in the same datacenter environment. Numerous versions of Unix and Windows will be accessing the identical database. The DBA administrators, the auditors, the oversight administrators and a wide number of final users will be running millions of queries per hour that access a shared database. The users will only retrieve data from databases, which are “owned” by the DBAs. However, it is possible that without appropriate safeguards there may be too many individuals that will have access to a database. Unless such access is controlled and fully accounted for there will be an exposure that damage to the database could arise from many sources.
There are many methods for attacking databases. One of these, and perhaps the most persistent means is through a “trojanization” of code. To trojanize a software product, one of the diverse and high turnover contractor employees doesn’t even have to actually write an entire backdoor into an application. Instead, the malicious developer could purposefully write code that contains an exploitable flaw, such as a buffer overflow, that would let an attacker take over the machine while a database application is restarted. Effectively, such a purposeful flaw will act just like a backdoor. If the trojan sneaks by the DBA, the malware developer would be the only one who knows about the hole. By exploiting that flaw, the flaw perpetrator could control the database using such code at a time of their choosing. For this reason the DBA will have to see that the interactions between applications and the database are totally isolated.
The DBA will always have access privileges and attach a debugger to any database process, to record all operations, to reset function and to modify how the database system works. There are many libraries and tools to do it. Each vendor provides own proprietary tools for that purpose. There are also numerous other open source and proprietary software available for extracting data or for modifying data bases such as DUDE (Database Unloading by Data Extraction). *
Under extraordinary circumstances the DBAs must be able to recover and reconstitute data files. That can be a complex and time-consuming procedure especially if the database was encrypted. Such recovery must take place under the surveillance by qualified personnel. An attacker can always induce a system failure and apply changes to the database software during the recovery without making it a suspicious act.
SUMMARY
It has been reported that DoD presently operates over 750 data centers and runs thousands of applications. There must be thousands of databases that pass information back and forth for interoperability. The risk that at least one of these databases will become a source of infection is a security exposure. Software protection, such as properly administered “vaults” can offer protection in such cases. However, the software “vault” must not be a part of an application but must be a DBA responsibility.
The personnel with DBA responsibilities will remain the holders of the most critical role in the management of DoD information assets. Though there is a long list of security measures that all must be put in place to assure that appropriate processes are in place, the elimination of compromises from an insider cannot be regulated only by procedures. The security of DBAs, as well as of all personnel auditing the functions of the DBA, deserves at least SECRET level of clearance. TOP SECRET clearance is warranted for all DBA related positions involving warfare. Whether such increases in security can be achieved with the current DoD reliance on contractor personnel must be demonstrated.
The current proliferation of diverse database cannot be fixed in the short run. The best one can do is to reduce the number of DBAs in DoD, to assure their security clearance, to increase the number of civil service personnel and to conduct the oversight of database surveillance procedures exclusively through military officers.
* http://www.ora600.nl/introduction.htm