General security

Deploying Biometrics: The Database Aspect

Overview of the Last Article

In any business or corporation, change is always a must. Whether it is for strategic or operative reasons, to flourish, change must always be embraced. In fact, this cannot be even more true in today's Security world as well.

Every day, we keep hearing of major Cyberthreats, which in hindsight, had the potential to be avoided in the first place. Just to name a few, there were the Sony, Target Stores, and the Anthem Blue Cross/Shield breaches. The latter two dealt the massive threat of credit card numbers as well as usernames and passwords.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

In this regard, change is a must for organizations all over the world, on a minute by minute basis. In fact, this can be likened to that of a cat and mouse game, where the business or corporation is the mouse, and the Cyberattacker is the cat.

But regardless, change in this aspect can also be very scary and daunting proposition not only for the employees of the organization but also for the C-Level Executives as well who are trying to protect and safeguard their company's assets as well (especially the Intellectual Property).

After all, their reputations are on the line as well, as they will be the first to get blamed if a Cybersecurity breach were actually to occur.

Our last three articles have reviewed in great detail (as well as provided a step by step process) as to what it will take for a C-Level Executive to fully procure, deploy, and implement a Biometrics Security system at their respective business.

Simple installations are of course easy enough, but if the planned deployment is going to be a large one, then a complete Biometric Project Management plan is necessary.

In fact, one of the main goals of these articles has been to provide this necessary framework. Our last one examined these four areas of the Biometric Project Management Plan:

• The System Architectural and Processing Designs:
  This can be considered the blueprint for the entire Biometrics deployment and installation (both from a hardware and software perspective).
• Storage and Matching:
  This aspect covers how the raw images which are collected will be converted over into their respective Enrollment and Verification Templates.
• The Operational Architecture Design:
  This part examines how Biometrics can work in a Multimodal approach from within a legacy security system at the business or corporation.
• The Information Processing Architecture:
  This area reviews the mathematical algorithms which are needed to convert the raw images into the Biometric Templates and the how the Enrollment and Verification Templates will be with against one another.
• Subsystem Analysis and Design:
  This part details as to what the exact sub-components of the entire Biometric System are.

This article continues with the theme of Biometric Project Management-focusing in on the database aspect of it. This is often the most forgotten about a component in Biometrics, as well as the most vulnerable to Cyber based attacks and threats.

Introduction to Biometric Databases

The database of a Biometric system is unique in that it houses both the Enrollment and Verification Templates of the end user population. Although it is typically not done, even the raw images can be stored as well (if this is done, one of the main priorities is to notify the employees of the business or corporation of this, and the reasons why it is being stored).

These databases can be housed in the particular modality itself, or at the server level if a Client-server network topology is utilized. How the database will be used depends primarily upon two factors:

1. The employee size of the organization;
2. The application which the modality will serve.

Typically, a small to medium sized business will use a Biometric device in what is known as a "Stand Alone Mode." In these instances, the various modalities will operate on their own, and their respective databases will store the Biometric Templates within just that device itself.

All Verification and/or Identification transactions will also transpire at that level. Typically these databases are very simple, and have already been installed and configured by the vendors themselves. In other words, the databases can be considered to be "off the shelf and ready to go."

In most cases, it is the larger corporations and businesses which will utilize the Client server network approach. Some of the reasons for this include much more sophisticated Security needs, and other office locations dispersed in other geographic regions. In these instances, the Biometric devices are all networked together, and linked up to a central server(s).

The databases are typically housed here, because of the sheer volume and the complexity of the Biometric Templates and the associated transactions which are taking place.

For instance, it is not just the Templates from one modality which is being transmitted and contained in the repository, the Templates of other modalities are also being stored as well (for example both Fingerprint Recognition and Iris Recognition), thus increasing the complexity and structure of the Biometrics database.

Although reviewing the design of a Biometrics database is out of the scope of this article, it will address some of the important issues and considerations from a Project Management perspective, such as:

1. Subsystem Deployment Considerations
2. The Database Management System
3. Determining the Security Threshold
4. Penetration Testing the Biometrics Database
5. A Simulated Penetration Test and Attack On A SQL Server Database.

Data Storage Subsystem Design Considerations

The Biometrics Database can actually be considered as a subsystem of the overall system, albeit it is a very important component. The construction of this kind of database is a very complex task, and at a macro level, some of its factors need to be examined very closely.

These include examining how the Biometrics database will fit into the overall security needs of the business or corporation; and how it will be managed.

It is important to keep in mind that the management of this kind of database is a very different endeavor than administering the modalities which are associated with it.

For example, a small database which has been created for a 1:1 Verification application will be much easier to manage (such as that of a Single Sign On) than a database which has been designed for a much larger scale, 1:N Identification application (such as that of using the AFIS database for Federal law enforcement purposes).

Also, the developers of the Biometrics database need to decide if separate subsystems will have to be designed for the Enrollment and Verification Templates, or if they can all be stored within the same subsystem.

Another crucial design issue is if other information and data about the Biometric Templates will be stored as well, such as the metadata.

A larger database will also mean that more optimization will be needed on a daily basis, to make sure that the Verification and/or Identification transactions can take place within the time frames established by the Vendor (which is typically less than two seconds).

This will also translate into more CPU processing power which is required because the query and search times will be greatly enhanced and much more demanding.

It was pointed out earlier that the raw images are typically stored in the Biometrics Database, but if the need arises, they can be housed in it. Apart from the social ramifications this brings, there are other technical considerations which need to be examined from the standpoint of the database. These include the following:

1. It is highly recommended that the raw images which are collected and/or recorded be stored into a different section of the database to help keep the performance optimized. In fact, it is even highly advised that if there are a large amount of raw images which have to be stored, a separate database should be created for that very purpose.
2. It should be noted that if a database query has to be run against the raw images, the search times could be very slow. This is because the file size of them are much larger than that of the Biometric Templates (which in comparison, are much smaller in size because they are just mathematical files).
3. The raw images, if they are stored in a database, will need to be reformatted, so that they can be used to replace the Biometric Templates if they degrade regarding quality over time, or if they are accidentally deleted, or are damaged/covertly hijacked due to a Cyber based attack.
4. The raw images which are stored in the database will need to have extra levels of Security. However, the protocols which will be implemented will be different than the Security protocols which have been set forth and implemented for the Biometric Templates.

The Database Management System

A Biometrics Database is normally run, administered, and maintained by a process known as the "Database Management System," also known as a "DBMS" for short. A business or corporation which is going to implement a large scale system and requires a Biometrics Database can either utilize an Open Source or a Closed Source platform.

With the former, the software code is freely available in which to construct and customize the database (examples of this include PostGRE SQL and MySQL). But with the latter, the software code is provided by a vendor (examples of this include SQL Server from Microsoft and the database software from Oracle).

But, it should be noted that there are advantages and disadvantages to using either approach. For example, with the Closed Source platform, there is direct technical support provided by the Software Vendor, but the licensing fees which are associated with it would be too cost prohibitive for a smaller business or corporation if they needed to utilize the Client server network topology.

With the Open Source platform, the technical support is free, and there are no licensing cost issues. But, since the software code is publicly available, it can be much more susceptible to covert Cyber-attacks.

There are other considerations when deciding upon either utilizing an Open Source or a Closed Source platform when establishing the "blueprint" for the Biometrics Database:

1. The maximum number of end users and their corresponding Templates which can be stored in the database;
2. How the Biometrics DBMS will handle search and retrieval requests;
3. How the overall structure of the database will look like;
4. If and when parallel and distributed processing (which was discussed in detail in the last article) will be utilized;
5. The specific disaster recovery plans for the Biometrics DBMS and the corresponding database structure;
6. The frequency in which the Biometric information and data will be "cleansed" by the DBMS.

The structure of the matching subsystem part of the database (this is where the Enrollment and Verification Templates will be compared against one another), will be dictated primarily by the type of modality which is being used (such as either Fingerprint Recognition or Iris Recognition).

With regards to the decision subsystem part of the database (this is where the final decision will be made whether or not to confirm the identity of the individual in question, and whether or not to grant him or her access to the resources they are seeking to use), more specialized considerations need to be taken into account by the database developer(s).

These include the following:

1. Whether a supervised or a nonsupervised system will be utilized;
2. The point at which a positive or a negative Verification Transaction will be made based upon the comparison of the Enrollment and Verification Templates;
3. If only one Security threshold will be used or other Security thresholds will be used as well to provide a sense of randomness to the Biometric System.

Determining the Security Threshold

As other articles have reviewed, to Verify or Identify a particular individual, it is the Enrollment and the Verification Templates which are compared with one another. In the real world, there is never a perfect match between the two, so therefore, it is the degree of similarity which is examined. If the two are deemed to be close enough via statistical tests which are conducted, then the individual is Verified or Identified.

But on the other hand, if there is not enough similarity, then the individual will be "rejected" by the Biometric system.

Ascertaining what the level of similarity should be is also known more specifically as "Determining the Security Threshold." This is actually a very difficult and complex process to achieve because this is often a subjective decision-making process.

This is often left to the discretion of the Network or Security Administrator of the business or corporation.

Deciding what the Security Threshold should be can also take quite some to determine. For example:

1. Determining what the exact level should be done first in a test environment. A snapshot of the Biometrics Database should be used here before the defined level is released into the production environment.
2. Ascertaining what the true, optimal Security Threshold should be is further exacerbated by the fact that it is also statistically very difficult to determine what the False Acceptance Rate (FAR) and what the False Rejection Rate (FRR) will be. For instance, the metrics in the test environment could vary greatly from what the production environment will produce.

Also, two other key factors that are very important in quantifying the Security Threshold level is the type of Biometric Modality which is being used, and the exact application of which it will serve.

If more than one Security Threshold (this is also known as a "Variable Security Threshold") is decided upon, then different statistical weights will have to be assigned to the numerous criteria that are being utilized.

Finally, the C-Level Executive and the IT staff of the business or corporation should keep in mind that there is a steep tradeoff between end user convenience and meeting the security needs of the organization.

For example, if the convenience of the end user population (in this case, the employees) is valued over security, this is called a "Liberal Security Threshold" setting. On the contrary, if security is valued over the convenience of the end user population, this is called a "Conservative Security Threshold" setting. Most Biometric applications lie in between these two extremes.

The defined Threshold Setting(s) and the Verification/Identification transaction occur from within the level of the Biometrics Database. With this in mind, before it can be fully deployed and declared to be completely operational in an organization, it must first be full Penetration Tested (also known as "Pen Tested") in order to ensure that it meets all of the Security requirements which have been set forth in the Biometric Project Management plan.

Penetration Testing the Biometrics Database

For any business or corporation, data is probably of the most valuable assets it can possess, especially in the way of customer information, thus securing the database upon which this resides becomes of prime importance.

Regarding a Biometric System, the Templates and the Verification and/or Identification data is probably one of the most valuable components as well. Thus, securing this specialized database becomes just as equally important. In fact, this should be one of the top priorities in any Security Policies and Disaster Recovery plans.

As it has been described, a Biometrics Database can be mostly created and built on just about any kind of database platform. Examples of these include the following:

• SQL Server
• MySQL
• Oracle
• Sybase
• PostGreSQL
• MongoDB

One of the best ways to confirm the integrity of the Biometrics Database is to formulate and conduct a Penetration Testing plan. As it relates to a database, this is known specifically as "Vulnerability Assessment and Penetration Testing," or "VAPT" for short. This type of Penetration Testing can evolve in three different formats, which are as follows:

1. Simulating attacks from both authorized and non-authorized users.
2. Conducting attacks against the security layers which have been implemented to protect the Biometric Templates, its metadata, and the Verification and/or Identification processing subsystem. These include the Encryption Algorithms and the Hashing Techniques being used.
3. Conducting simulated Cyber based attacks to determine how "hard" the Biometrics Database really is regarding thwarting off both internal and external threats/risks;
4. Launching a Risk Finding Test to pinpoint and seal off the hidden vulnerabilities in the Biometrics Database.
5. Using SQL Injection Tests to make sure that that the end user inputs the correct characters in the application fields when querying for the information and data. For example, if there any special characters such as "," or ";" which can be inputted, this can be considered to be a major security vulnerability, because a hacker can then covertly hijack the "content" in the database. This is known specifically as an "SQL Injection Attack," and to avoid this risk, it is highly recommended that only text-based characters should be inputted into the query fields. It is also very important to test for brackets, commas, and quotation marks.
6. Deploying a Password Cracking Program to check for the entropy and the strength of the passwords which have been assigned to the end users. In other words, the goal of this is to make sure that they cannot be easily figured out by a hacker if they were to launch a dictionary attack against the Biometrics Database. This should be taken seriously, as this is deemed to be one of the most important Penetration Tests which can be conducted.
7. Running a Security Audit of the Biometrics Database to confirm and ensure that the appropriate Security Policies and Standards are being enforced into the Biometrics Database.

The following are some specific Penetration Testing Tools which can be used on a Biometrics Database, and they are as follows:

1. Zed Attack Proxy:
   This can be used to find any Security vulnerabilities in any web applications that the Biometrics Database may have programmed into it. For instance, this includes an Internet-based Remote Interface that an end user can utilize if they are working from a geographically separate location from their normal, on-site workplace.
2. Paros:
   This package checks for any malicious HTTP and HTTPS based data between the client tool and the server that the Biometrics Database resides upon. Examples of this include any form fields and cookies which are transmitted back and forth.
3. Vega:
   This is a sophisticated tool which can easily detect for any instances of SQL Injection and Cross Site Scripting vulnerabilities in the Biometrics Database.
4. Wapiti:
   This is a package which scans the for any Web-based pages or applications that the Biometrics Database utilizes. Specifically, any gaps or holes in which malicious code can be injected (it does not necessarily have to be SQL based code) is examined for and literally sealed off.
5. Web Scarab:
   This is a Java-based tool which offers deep scanning capabilities in any HTTP or HTTPS communications which the Biometrics Database may utilize to access any information or data which resides in it.

It should be noted that the above-mentioned Penetration Testing Tools can be all automated on the Biometrics Database, thus offering the following benefits:

• The rapid identification of configuration errors, default settings, coding errors, and any software patch management issues;
• They can be run on a regular basis to help provide both baseline and ongoing vulnerability management metrics in real-time;
• They can free up the valuable time of the Biometrics Database Administrator to focus on issues which require greater attention and human input/intervention.

A Simulated Penetration Test and Attack On A SQL Server Database

Most businesses and corporations typically operate in a Windows environment; so thus, they will be using primarily Microsoft based tools. In the case of a database, this would be SQL Server, and as mentioned, this platform can even be used to create and deploy even a large scale Biometrics Database.

In this regard, a Penetration Test would be to determine on which Port number an instance of SQL Server is running on. This is a common practice amongst hackers, to launch a Cyber-attack on a database.

SQL Server databases instances are typically run on Port number 1433, but a Database Administrator may choose to utilize a different port in order to help "mask" it. To determine this, a Penetration Tester can use a tool known as the "SQL Server Browser Service," which typically runs on Port number 1434. Another popular tool which is used is known as the "metasploit module mssql_ping."

Using this, it is found that the SQL Server instance being run is Windows 2000. From this, and analyzing more information, the next step in the Penetration Test is covertly determined a username and password combination (and the Port Number which it resides upon) to gain access to the database.

There are a number of ways to do this (such as launching a SQL Server Injection attack or using Windows Shares), but a more powerful tool which is used by the Cyberattacker is known as "Metasploit Framework."

By launching the following command line:

auxiliary/scanner/mssql/mssql_login

There are not any obvious credentials found. Although there are no username and passwords which are evident here, in these cases, the Database Administrator, very often uses a very simple password which is easy to guess. For example, it could be a combination of the name of the company and street address; the name of the company itself; or even using "password" as the password.

Once these specific credentials have been determined, then other "Metasploit Modules" can be used to launch to determine the Security integrity of the SQL Server database, to find any holes, gaps, or other vulnerabilities from which to launch to a Cyber-attack.

From here, a Cyber attacker can determine the following:

• Other username/password combinations;
• Any super-user privileges which may have been established;
• Other databases which may be in existence.

Of course, once the hacker determines all of this, more information can then be gleaned from the tables and records of the database and the information/data that they contain. It's just then a matter of time until an attack is launched against the Biometrics Database, and vital metadata is then captured and fully exploited.

Conclusions

Overall, this article has continued with the theme of the importance of a Biometrics Project Management plan, with an emphasis primarily on the database infrastructure aspect of it. When a C-Level Executive starts to examine the prospects of deploying a Biometrics System, it is the thoughts of just procuring the hardware which comes to mind.

But, there is a lot more than the hardware which needs to very carefully considered, such as the database aspects. After all, it is here where the Biometric Templates are stored at, and where the Verification/Identification transactions occur.

This part of the overall Biometrics System needs the strongest level of protection possible because this is where the Cyber attacker is going to look first to launch an attack (as demonstrated in the last section).

Our next article will examine that part of the Biometrics Project Plan which involves the overall system testing, maintenance, upgrading, and networking.

Sources

https://pentestlab.blog/2013/03/18/penetration-testing-sql-servers/

https://www.trustwave.com/Resources/SpiderLabs-Blog/Oracle-Databases,-a-Penetration-Tester-s-View-of-Unauthorized-Access-to-Customer-Records/

https://www.pivotpointsecurity.com/penetration-testing/database/

https://www.tutorialspoint.com/database_testing/database_testing_security.htm

http://www.valencynetworks.com/penetration-testing-services/database-testing.html

http://picateshackz.com/2016/01/kali-linux-tools-for-web-app-database-pentest.html

https://www.hackingloops.com/how-to-perform-penetration-testing-of-mysql-database/

http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Fan-Rong.pdf

https://www.lexisnexis.com/risk/downloads/whitepaper/biometrics-wp-en-us.pdf

http://www.idsysgroup.com/ftp/BestPractice.pdf

http://www.smartcardalliance.org/secure/reports/FIPS_201_Migration_WP.pdf

https://arxiv.org/pdf/1605.03116.pdf

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r2.pdf

https://cloudsecurityalliance.org/csaguide.pdf

http://www.cgdev.org/files/1426862_file_Biometric_ID_for_Development.pdf

http://www.academypublisher.com/jsw/vol02/no04/jsw02042431.pdf

http://www.smartcardalliance.org/resources/pdf/identity_faq.pdf

http://www.akamaiuniversity.us/PJST13_1_300.pdf

http://www.biometrics.gov/documents/biotestingandstats.pdf

http://www.cse.msu.edu/~rossarun/BiometricsTextBook/Papers/Security/JainNandakumarNagar_TemplateSecuritySurvey_EURASIP08.pdf

http://precisebiometrics.com/wp-content/uploads/2014/11/White-Paper-Understanding-Biometric-Performance-Evaluation.pdf

https://danishbiometrics.files.wordpress.com/2009/08/1-13.pdf

https://www.blackhat.com/docs/us-15/materials/us-15-Keenan-Hidden-Risks-Of-Biometric-Identifiers-And-How-To-Avoid-Them-wp.pdf

http://publications.idiap.ch/downloads/papers/2015/Hadid_SIGPRO_2015.pdf

http://www.mecs-press.org/ijigsp/ijigsp-v6-n2/IJIGSP-V6-N2-6.pdf

https://pentestlab.blog/2013/03/18/penetraton-testng-sql-servers/

https://www.trustwave.com/Resources/SpiderLabs-Blog/Oracle-Databases,-a-Penetraton-Tester-s-View-of-Unauthorized-Access-to-Customer-Records/

https://www.pivotpointsecurity.com/penetraton-testng/database/

https://www.tutorialspoint.com/database_testng/database_testng_security.htm

http://www.valencynetworks.com/penetraton-testng-services/database-testng.html

http://picateshackz.com/2016/01/kali-linux-tools-for-web-app-database-pentest.html

https://www.hackingloops.com/how-to-perform-penetraton-testng-of-mysql-database/

http://www.blackhat.com/presentatons/bh-usa-06/BH-US-06-Fan-Rong.pdf