Open source postgre SQL database security

GENERAL OPEN SOURCE AND POSTGRESQL DATABASE SECURITY
Student Name
Instructor
Date












Introduction
A Topical Overview
Database security is identified by IBM researcher, Bernier (2009), as “the single biggest concern with today’s web-based applications” (p. 1). When secured data is compromised, it risks exposing sensitive information about the organization and its customers to unauthorized personnel (Bernier, 2009). Both of these exposures carry with them the ability to cause an organization to fail either through loss of funds, inability to provide service or loss of confidence by clients. In the mainstream media today, there are no shortages of stories related to crackers accessing corporate databases for nefarious purposes (Bernier, 2009). This has raised a great deal of concern in the court of public opinion and the degree to which these concerns are valid is a subject of much debate. In terms of general database security, unauthorized access to a database cannot be prevented in all circumstances (Bernier, 2009). Open source programs, which are heralded by some as being more secure and others as being less secure, stand at the forefront of the complex and multifaceted discussion on web security. As databases have become more normalized for sensitive information, those wishing to gain unauthorized access to data for criminal purposes have too become more sophisticated. Today, it has been stated that “data harvesting is a big business and is accomplished by dedicated experts who work within a corporate infrastructure” (Bernier, 2009, p. 1). While an impenetrable database my be a thing of fiction, there is a great deal that can be done related to ease of unauthorized access and the degree to which unauthorized access can cause damage. Security, therefore, is part prevention and part reduction of damage.
Research Questions
Based on the current state of open source security knowledge, the following research questions have been formulated for exploration in the following study:
1). To what extent is open source database secure and to what extent is PostgreSQL secure?
2). What are the security measures needed to be taken to protect open source database, specifically PostgreSQL?
3). What are the risks associated with open source database and what are the guidelines to be followed by developers when developing to mitigate these risks?
Significance of Research
The use of databases in organizations is now the norm rather than the exception. In addition, there is a growing use and popularity of open source style programs. Both for veteran organizations of databases and those who are new to utilization of databases, having the best potential security in place and security practices in place are key to organizational efficiency, personnel data management and client data management. At the minimum, in order to be competitive, organizations have to have industry standard security in place. Having beyond industry standard security, however, would be even more advantageous. It is also important to note that database security is a process rather than a destination. With the rapid advancement of technology, often times those with malicious intent are more advanced than the IT professionals in charge of security at a given organization. Answering the research questions will provide an outline for the degree to which open source is secure, PostgreSQL is secure and what measures can be taken to maximize security protocols.
Definition of Key Terminology
Hacker. A person who explores, discovers and inquires with the intention to understand technology (Bernier, 2009). Among peers in the IT community, to be labeled a “hacker” is a badge of honor due to the expertise it takes to be considered such (Bernier, 2009). In the general public, the term hacker is often confused with “cracker” and usually is considered to be negative. This is a factor that has only been compounded by the misuse of the terminology in the mainstream media.
Cracker. A cracker is generally what the general public considers to be a “hacker.” A cracker is hacker that operates with malicious intent including but not limited to vandalism, credit card fraud, piracy, identity theft and other types of illegal activity (Bernier, 2009). Cracker related crime can be entirely online or it often times has a physical component as well. This crime is one that is currently on the rise in the 21st Century and its nature is so new that there is no precedence for dealing with such activity.
Open Source. “Open source is a philosophy that promotes the free access and distribution of an end product, usually software or a program” (Open Source, 2015). This terminology has increased as the growth of the Internet necessitated the reworking of massive amounts of program source code (Open Source, 2015). Codes that are open to the public allow for different communication paths and diverse array of new models because different people are working together on the same problem with different approaches (Open Source, 2015). Some suggest this methodology increases efficacy of programs and makes them more secure.
PostgreSQL. This is a type of open source, object relational database management system (PostgreSQL, 2015). It is not owned or controlled by any one company or individual (PostgreSQL, 2015). This platform began as a research project at the University of California, Berkley, and has a long history dating back to 1985 (Obe & Hsu, 2015). The open source nature of the software means that it is managed through coordinated online efforts facilitated through enthusiasts, an activity global community of developers and other volunteers (PostgreSQL, 2015). It was first released in the mid-1990’s and it is written in C (PostgreSQL, 2015). It is not controlled by a corporation or private entity and the code is available free of charge (Rouse, 2016). The competition for the software includes: Oracle DB, SQL Server and MySQL (PostgreSQL, 2015). Advocates suggest that it is more than a database because it also has an application platform that makes it extremely flexible (Obe & Hsue, 2015).
Outline
In an effort to answer the proposed research questions, this work will produce data through a review of previously published literature on the subject and a single item questionnaire provided to 10 IT professionals. Limitations of research will be considered and recommendations for future research will be proposed.
Methods
This descriptive study is based on a mixed methods platform that examines quantitative results of single item questionnaire that was provided to 10 IT professionals. It also includes the exploration of robust sources of academic and industry based literature that has been published on the subject. Content analysis based descriptive studies are a widely employed methodology in both qualitative and quantitative research (Content, 2016). It focuses on broad communication and can have varying degrees of formalization (Content, 2016). Content analysis utilizes three distinct approached to data collection: conventional, directed and summative (Content, 2016). This study will employ summaries of what is known in published research about the subject and it will establish the general consensus and/or debates that are present within the published research (Content, 2016). Sources that will be employed come from texts, hypertexts, written books and periodicals. Beyond the literature review content, the opinions of the IT professionals collected will be considered within the context of the other descriptive data collected to see if symmetry or lack of symmetry is present in the research findings. Common thematic will be expressed and considered as per descriptive analysis modalities (Descriptive, 2016). The content analysis of existing literature will be the overall foundation of the research study. The questionnaire provided is utilized for the expressed purpose of gaining opinions related to the experiences of IT professionals. The nature of their perspectives are based on personal experience and are therefore not necessarily congruent with peer reviewed findings on the subject. This dual approach is employed to see if IT professionals are in agreement on security related considerations of open source software.
Academic research was selected based on the following parameters: (1) year of publication (nothing older than 2010), (2) authority of author, (3) reputability of the publication/platform and (4) usefulness to answering the research questions. If the source was too old, if the authority of the author could not be verified or the reputation of the publication/platform could not be verified, the source was thrown out. Those employed in the research study all met the four criteria as expressed by the researcher. The questionnaire provided to the IT professionals consisted of one close ended question established on a Likert scale (Garson, 2013). The question asked the following “To what extent is open source database secure?” The responses fell on the continuum of 1-5 with (1) highly vulnerable (2) not secure (3) as secure as possible (4) somewhat secure and (5) very secure. The individuals selected were from a closed group of professionals that were acquaintances of the researcher. Each of the IT professionals had either two or four year degrees in some aspect of IT and at least 4 years of experience in the field. After the data is collected by the researcher, reoccurring themes will be established and considered. In addition, symmetry with the perspectives of the IT professionals surveyed will also be considered.

Research
Qualitative Data
The way in which the media depicts database security issues is not an accurate illustration of one program’s security superiority over another (Haas, 2015). For example, in recent publications, the NoSQL database solution has come under criticism related to their security postures (Haas, 2015). While this is problematic for the image of a database and for public confidence, it does not necessarily irrefutably demonstrate inferiority to another platform (Haas, 2015). By their nature, it would appear that having an open source platform, being that is available to virtually anyone, would be less secure than one of their closed counterparts. While this can be the case, as will be examined later in the work, much of the security paradigm related to open source databases rests in the application of the format as opposed to innate weaknesses. This is a notion that is realized by a variety of organizations and IT professionals. Mohamed (2016) found that there are growing numbers of organizations who are trusting mission critical applications to open source databases. For example MySQL AB is now competing with closed database giants like Microsoft, Oracle and IBM and is winning business over these proven competitors (Mohamed, 2016). If open ended databases were innately inferior and this was considered to be a fact rather than an opinion by industry professionals, it would be difficult for open source platforms to compete. Open source is not only competing, in some instances it is winning (Mohamed, 2016; Lawton, 2010).
With growth, however, comes vulnerability issues. For Ingres and MySQL, they are being employed for large scale commercial applications as they support web commerce sites and are growing in use as fast as their commercial counterparts (Lane, 2010). When cost or flexibility is an issue, organizations are establishing open source as a viable alternative (Lane, 2010). Lane (2010) states that these platforms are not less secure by nature, but they lack the supporting security knowledge and related applications that are readily available on other platforms (Lane, 2010). As a result of this element, it can be stated that there is a higher propensity for security oversights when applying open source applications. In general, the people that are applying and that have crafted open source programs are not security professionals, “they don’t spend their days researching security threats, and they don’t know what to look for.” (Lane, 2010, p. 1). Lane identifies questions they may not be able to answer as including “What does the attack look like,” “What is a suitable resolution,” and “Are patches available?” (Lane, 2010, p. 1). Knowing these variables would be necessary for determining whether or not there are work arounds or resolutions (Lane, 2010).
For smaller firms, the cost effective nature of open source programs could cause problems in relation to security costs when time is considered for monitoring vulnerabilities. Writing queries to find information consumes valuable time that can be used in other places (Lane, 2010). Lane (2010) explained of the practicality of the open source security,
One of the aspects I hated most about creating assessment policies was writing the queries as a simple check, which could take a day to write and optimize, then test it across all revisions of the database. It might be cost-effective for very large firms to do, but small security firms have trouble justifying the cost of this development (p. 1).

Saving money on the open source application may mean that further resources have to be devoted to the application for security in the future. For long term savings, this may not even out. If a small organization is trying to save money in the short term why they build, this may be a viable practice as the IT department could expand by the time these security protocols are necessary. Stating that one is better or worse, therefore, is an exercise in futility as it is really contingent on the needs and unique nature of the organization in question. It also should be noted that the use of automation for gathering user permissions, manually comparing settings/policies, and keeping up to date wit patches is very time consuming and mistake prone (Lane, 2010). The “many eyes” theory of open source is the most frequent argument that is presented to identify its potential for being a more secure platform than its counterparts. Some have suggested that this theory of increased security is highly debatable (Roberts, 2015; Donevski, 2012). Frucheterman (2015) believes that open source is not only compatible with the needs of digital security but it is also essential for it. Heath (2013), in contrast, stated that it is no more secure or less secure than proprietary software. Heath (2013) created a full list of what he considers to be myths related to open source security that include: Open source software is more/less secure than proprietary, many eyes makes for secure code, bad people can look at the source code so it’s less secure, anyone can contribute to the code so it’s all bad, open source software means it’s open for your organization to use and all software must be evaluated for security.
Being that PostgreSQL is an open source database, the generalized findings related to open source security would also be applicable to this platform. Beyond these generalizations that were previously expressed, however, is a robust plethora of academic research regarding specific PostgreSQL vulnerabilities. Built into the open source PostgreSQL platform is a database security addressed on several levels. According to PostgreSQL (2015), database file protection manifests because all files are stored are protecting from reading by any account other than the Postgres superuser account. The superuser account can be considered master accounts and it allows for certain types of information to be blocked by certain types of users. Simply getting into the system, therefore, is not enough to gain access to everything within the system. This application most readily keeps authorized personnel who can log into the system from getting information that they do not need. This addresses the “inside job” or non cracker style data breach.
Further protections include the way in which the client can access the database. By default, these connections are only allowed via a local Unix socket and not via TCP/IP sockets (PostgreSQL, 2015). Backend has to start with -i in order to allow non local clients to connect (PostgreSQL, 2015). These external connections can also have IP restrictions. For example, the database can restrict IP addresses and user name via pg_hba.onf file in PG_DATA (PostgreSQL, 2015). Additional restrictions can also come in the form of client connections having to be authenticated through user names and passwords (PostgreSQL, 2015). A user would not have access to any database that they did not create so they could not get other sensitive data in which they are unauthorized to see. It is also possible to assign individuals to groups and based on the tier of their particular “group,” this would restrict or allow access to certain areas (PostgreSQL, 2015). This would mean that for employees, it is possible to have a management group that allows for organizational managers to have access to data that a general employee or client would not. Of course this type of information would have to be password protected or restricted to certain areas of login. If a person were to gain access to a managers password, theoretically they would be able to get all the data available to that group.
Haas (2015) explored the subject in depth of securing PostgreSQL platforms and concluded that most of the vulnerabilities present in applications of the database can be cured or avoided with common sense. One of the most important steps he considers to be a “common sense” practice is putting the PostgresSQL database or any other network facing services present behind the corporate firewall (Haas, 2015). Though maybe obvious, there are times when this critical step is ignored. He explained, “Even the best written software will occasionally have security vulnerabilities that can be exploited merely by connecting to the port it runs on” (p. 1). Haas (2015) further recommends the use of listen_addresses settings that will prevent connections from networks that do not require database access. In the event that another setting is being employed but access to the database is not necessary from any other server, it can be further secured by setting listen_addresses to ‘localhost.” He contends that this is not as good as a traditional firewall, but it is very close to being as efficacious (Haas, 2015).
There are other ways that can restrict the ability to connect to the database. Specifically, the use of pg_hba.conf can force connections to the database to employ SSL encryption and it can be configured to accept or reject connection attempts by IP addresses (Haas, 2015). Authentication protocols can also be put into place in order to make a connection with some options available including but not limited to: LDAP, RADIUS, PAM, Kerberos, SSPI and GSSAPI (Haas, 2015). Further security can also be provided by using replication access (Haas, 2015). These should be considered very important because they are generally automated and they have no passwords but still contain high level access to the database (Haas, 2015). Even superuser access can be locked down within this spectrum (Haas, 2015). The restriction of login to certain areas of the database are also important. Users should not be able to run as a superuser unless it is absolutely necessary (Haas, 2015). People entering the database should only have the privileges that they need and nothing beyond (Haas, 2015). Automated logins should be limited or disabled so unauthorized personnel cannot use someone else’s information at a machine in which they were just using (Haas, 2015). Column level permissions are also popular mechanisms for allow certain users to access certain types of information (Haas, 2015). Haas (2015) noted that PostgreSQL 9.5 offers row level security that has been available in EDB databases.
Haas (2015) contends that most of the security holes in PostgreSQL are not based on innate weaknesses in the open source platform, but in the application process. He cautions professionals to use common sense and to “not be dumb” when employing security measures in PostgreSQL (Haas, 2015). Though not specifically stated by Haas (2015), the security suggestions he emphasized would be a function of the database administrator (DBA). The more a DBA understands the potential security threats and the protocols in which he/she chooses to secure the potential threats will determine the degree to which the database is secure. As a result, Bernier (2009) came up with four things that organizations should consider when selecting a DBA for their PostgreSQL application. He stated that PostgreSQL DBA should have the following attributes: (1) knowledge of relational theory (family with SQL ’92,’99, and 2003), (2) the ability to read source code (C) and compile source code on Linux, (3) can system administrate and is comfortable with System-V UNIX and/or Linux and (4) can maintaing various hardware items found in IT (TCP OS layer, subnet a network, tune firewalls (Bernier, 2009). A DBA that cannot do any of those 4 applications will likely have a more porous PostgreSQL database than one who is familiar with all of those elements. There is a high contingency on the degree to which a system is secure and the personnel hired by the organization. Bernier (2009) stated that there are an abundance of DBAs that have skills to administrate, monitor and tune a database; however, PostgreSQL relies on OS’s utilities so those skilled in that as well will be at a greater advantage for dealing with security challenges.
With the role of the DBA established in the security process of PostgreSQL, Bernier (2009) goes on to establish the following specific dimensions for securing PostgreSQL open source: review of access privileges, roles/granting rights/privileges, superuser rights/privileges and accessing objects. Even with strong attention to passwords and password policy, there are still limitations in place. Using strongly typed passwords are a worthy goal but their strength cannot be judged until somebody actually cracks it (Bernier, 2009). In terms of password cracks, there are two methods: brute force and dictionary attacks (Bernier, 2009). Brute force is a methodical method of testing (Bernier, 2009). It begins with some letters and it increases in length as the attack continues and it can be best employed for testing short passwords (Bernier, 2009). Dictionary attacks can be considered a social engineering approach (Bernier, 2009). The cracking utility employs a dictionary of words and then generates combinations of those words taking “advantage of the erroneous belief that a long character string consisting of a mnemonic combination of strings and characters is safer than a slightly shorter length of randomly chosen ones” (Bernier, 2009, p. 1). The hardware employed and strength of a password could make such an attack taking anywhere from a few seconds to several months (Bernier, 2009). If the other protocols were followed, not all cracks for passwords would be created equal. In this capacity, cracking a basic employ on a lower tier access group would only give the outsider access to a limited amount of information. In contrast, cracking the password of a superuser could give an outsider access to nearly everything.
The best way to make these innate limitations most secure is by making sure that an ordinary user account is unable to own or create anything (Bernier, 2009). Since it is more likely that an outsider would gain access to general user account than a superuser account based on statistical probability, if the proper protocols are in place, a compromised user account could only do whatever it wants with the object it owns (Bernier, 2009). If ordinary user accounts were able to own or create content, an unauthorized access could allow for data mining of tables and modification of information by adding rules and triggers that would allow for later harvest of secure information (Bernier, 2009). Minimizing the amount of damage a normal user can cause is of the utmost importance for security against unauthorized cracking via a password.
To provide further clarity to the subject, knowing the innate PostgreSQL limits is also useful for the present discussion. For PostgreSQL, the maximum database size is unlimited, the maximum table size is 32TB, the maximum row size is 1.6TB, the maximum field size is 1GB, the maximum rows per table are unlimited, the maximum columns per table are 250-1600 and the maximum number of indexes per table are unlimited (PostgreSQL, 2016). These limitations and values are sufficiently robust for most applications and this has causes this open source database to gain a variety of praise from the industry and users (PostgreSQL, 2016). Specifically, PostgreSQL has won the Linux New Media Award for Best Database System and it is a five time winner of the Linux Journal Editors’ Choice Award for Best DBMS (PostgreSQL, 2016). Just like the various security protocols that have been illustrated, the entire platform is highly customizable and runs stored procedures in more than 12 programming languages (PostgreSQL, 2016). Its use, therefore, will likely continue to grow.
Quantitative Data
The Likert scale question established a less than favorable perspective on the open source safety by industry professionals. Seventy percent of respondents indicated that open source databases are as secure as possible. Twenty percent indicated that open sources were not secure and 10% of respondents indicated that open source databases are highly vulnerable. On a scale of 1-5 with 5 being the most secure, all respondents indicated open source as having a score of 3 or lower. Being that this represented a single question, this does not mean that the respondents were against open source or PostgreSQL specifically. It is possible that the respondents felt the systems were vulnerable but still considered them to be superior than some of the present alternatives that are possible. It does, however, present an interesting illustration of how vulnerable open sources are considered to be by industry insiders. This information could be taken one of two ways. It could be considered strong data because it was produced by industry insiders with in depth knowledge of how security for open sources looks in practice. On the other end of the equation, it can also be considered alarmist in nature because professionals are aware of all of the potential types of attacks that can occur even if they are unlikely. For example, knowing that there are hundreds of potential ways to crack into an open source like PostgreSQL, even if unlikely or time consuming, would probably make an individual more inclined to label something as being less than secure. The important element of this information is that it demonstrates that industry professionals do not consider open source very secure. Most see it as being as secure as possible, which means that attention to security for databases that use open code should be a focal point for any organization.
Though it was not part of the questionnaire, one of the respondents who answered his/her question via email wrote the following note along with their response:
This is a good thought provoking questions, but it’s hard to answer in a standalone capacity. As you see, I answered (3 As secure as possible). This means that I think open source can be as secure as anything else. It really all depends on the application. Non open source stuff has more tools available for developers and better security in place because of its a commercial application. So pretty much, non open source stuff is more secure just because of the team behind it and the interest of the providers in having a strong product, by nature, open source is not inferior, but Organization A and Organization B can both use PostgreSQL databases and one could be industry standard in terms of security and the other could be quite porous.... Anyway, this isn’t a simple question.

This additional data presented by one of the respondents echoes much of the sentiment that was expressed in the systematic review of literature explored in the qualitative section of the research. It was not the only additional response provided by a respondent. The following perspectives were also gathered and necessitated consideration by the researcher:
I have no problem with open source databases, it really boils down to who is monitoring them and who installed them. I’d say they are secure as they can possibility be based on the platform alone, not on the IT professional, which can vary a great deal.

The last response provided a summative element related to the information collected:
Nothing is secure, that’s why I gave open source a 1, I would give any database out right now either a 1 or a 2. That’s for open source or a closed commercial application. Some people aren’t comfortable with that, especially those outside of the industry. Security in programming is loaded question. The public doesn’t get this. If a human built the database, a human can get around the database. It’s a simple as that. I will admit some are harder to crack than others and let’s be honest, not everyone has the ability to crack a database. If everyone had this skill set the world would be a scary place.

The researcher specifically selected a close ended Likert scale instrument to produce quantitative data to be compared with the qualitative portion of this study. It was also the intent to introduce some original research into the subject so the entire scope of data presented was not focal on only previously published material. The inclusion of these additional insights were not intended; however, they provided valuable information that was synergetic to the other material collected. The robust nature of content analysis also allowed the entrance of such data to be considered thematically. It was the opinion of the researcher that the inclusion of this unintended data was useful to the study and that it was better study to include it. The results of the study would not change if they were removed so they can be considered additional insight into the matter that provided further depth and clarity.
Discussion
Based on themes present in the mixed methods data generation, the following conclusions have been reached in regards to the three research questions: (1). To what extent is open source database secure and to what extent is PostgreSQL secure? It can be stated that the open source database is fundamentally as secure as non open source platforms. As part of the same paradigm, the same can be stated of PostgreSQL. Rather than innate flaws present in the software that make it vulnerable, the primary vulnerabilities are related to the way in which it is structured and monitored by DBAs. While the previously published data thematically established the same elements, the individuals surveyed by the researcher also overwhelmingly had the same perspective on the subject. Seventy Percent of those surveyed felt that open source was as secure as anything else. Of the remaining 30% of respondents, 10% indicated that they would not consider any available software above a 40% rating on a scale of 1-5. It can be further concluded that at least 80% of respondents do not look at open source as being inferior to their counterparts on the level of security.
The second question proposed in the research was (2). What are the security measures needed to be taken to protect open source database, specifically PostgreSQL? This answer was more multifaceted but still adequately answered by the data collected. The necessary security steps included but were not limited to the following: Selection of skilled DBA (Bernier, 2009), place PostgresSQL behind existing firewalls (Haas, 2015), the use of listen_addresses settings to keep connections from networks that don’t require database access (Haas, 2015), Using pg_hba.conf to restrict connection to database (Haas, 2015), using SQL - Level permissions to control access to specific data base resources (Haas, 2015), restrict logins (particularly automated ones) (Haas, 2015), offer row level security (Haas, 2015), superuser managed (PostgreSQL, 2015), assigning groups for table access (PostgreSQL, 2015), review access privileges (Bernier, 2009), don’t allow general accounts to be able to own or create anything (Bernier, 2009) and staying abreast of new security developments in the IT field. In terms of the latter, it can be stated that knowledge is power in terms of unauthorized access. If a DBA is cognizant of methods that crackers are using to gain access to PostgreSQL databases, they can secure their own applications from such attacks. It is important to note that these security measures should be considered to be preventative tactics to minimize unauthorized access or damage that can be done in the event of unauthorized access. As it stands, the general consensus is that no software, open source or otherwise, can 100% be free of security risks. According to Mitnick (2016), “Companies spend millions of dollars on firewalls, encryption and secure access devices, and it’s money wasted, because none of these measures address the weakest link in the security chain” (p. 1). Mitnick (2016) goes on to further identify the weakest link as the people who use, administer, operate and account for computer systems that contain protected information. Even if a program were created that was “perfect” in terms of security, as Mitnick (2016) points out, the fact that it is operated by human beings makes it fallible.
The third research question asked the following: (3). What are the risks associated with open source database and what are the guidelines to be followed by developers when developing to mitigate these risks? The risks of using open source databases is not rooted in the fact that they are less secure by nature, but in the fact that they lack “supporting security knowledge and tools available on other platforms” (Lane, 2010, p. 1). This factor puts even more emphasis on the role of the DBA in the success or failure of securing open source databases. Other commercial platforms have specific teams designed for ensuring security, they are committed to making sure their clients are using the software correctly and they consider it part of their own business model for the client to have a favorable view of how their data is being secured. An open source is there as a cost effective alternative to commercial software applications. The degree to which it will be secure or not secure will rest on the way in which it is installed and monitored by the DBA (Bernier, 2009). Data harvesting in today’s world is big business and it is conducted by experts (Bernier, 2009). Those who wish to minimize the risk related to contending with these experts must too show equal or greater talent.
Conclusions
General
The results of the research study indicate that open source databases, including PostgreSQL are secure on an industry standard level. Open source databases can be a good solution for an organization if their innate strengths and weaknesses are complimentary to the resources available, personnel talent, time availability and overall understanding of the platform by the organization. While the innate limitations of open source databases are no more than their commercial counterparts, there are potential barriers in place related to time, application and monitoring that may keep them from always being the best choice for an organization. Their flexibility, however, will make them continue to be a strong database alternative in the present and in the foreseeable future. Having realistic expectations and a realistic understanding of one’s own organization would be critical for deciding whether or not to employ such a platform. Once it is determined that PostgreSQL is right for an organization, attention to the variables that were articulated in the research can make the open source database as secure as any of their commercial counterparts. Though the support tools may not be available to the extent to which they are in commercial software, they can be just as efficacious (Lane, 2010). It is also important to note that there are a growing number of security support tools available aimed at open source users. Among these include but are not limited to Nmap, OpenVAS, OSSEC, Security Onion, Metasploit Framework, OpenSSH, Wireshark, BackTrack, Nikto and Truecrypt (10 Essential, 2015; Krill, 2014).
Limitations of Research
While it can be stated that the overall strength of the research project was its reliance on previously published and relevant academic data, the lack of actual case studies to demonstrate and analyze cases of security breaches on open and commercial databases makes it hard to completely access the degree to which the security for each are equal or unequal to the other under specific conditions cannot be accessed. For example, knowing in which situations a particular commercial database is more secure over an open source under the same set of conditions could be a valuable tool for an organization to have when considering which database to choose. If it could be established that one is more effective for certain types of attacks, an organization could consider which attacks it is most likely to have and then make their choice accordingly. Beyond the case study specific variables of attacks that could be used for comparison, it can also be stated that the quantitative portion of the study did not dig deep enough into the question it asked and it did not necessarily provide enough of a sampling to be statistically significant. While it was useful as a supplement to the larger content analysis, alone that data would not be able to great larger generalizations that are useful to expanding knowledge in a given field of research. A larger sample and more questions could have remedied this deficiency. Though unintended, some degree of this limitation was assuaged by the fact that unprompted, some of those surveyed provided additional insight and explained their reasoning for choosing which number they did. Without this additional information, there would have been more room for conjecture or debate as to why the majority of respondents felt the way they did.
Suggestions for Future Research
Based on the previously established limitations, it can be stated that future research should be conducted on comparing case studies of security breaches related to both commercial and PostgreSQL databases. While this research has established that open source is not innately inferior to commercial software, it does not specifically articulate when and where these different programs are limited. Knowing specific variables related to specific software and actual instances where such elements took place would be useful to get a more complete picture of the success and limitations of open source at the present time. In addition, future research regarding IT professional perspectives could be conducted with a larger sampling and with more close ended Likert scale questions to provide greater detail related to the responses. Both suggestions would build on the research that was analyzed for the sake of this discourse. It is important to note that the limitations of the study were not sufficiently present to warrant the study not valid. The results still are valid and accurately demonstrate themes and generalizations that currently exist in what we known about open source programs and PostgreSQL security.














References
Garson, G.D. (2013). Scales and Measures. New York: Statistical Associates Publishers.
Lawton, G. (2010). Open source security: Opportunity or oxymoron? Computer, 35(3), 18-21.
Obe, R. & Hsu, L. (2015). PostgreSQL: UP and Running. New York: O'Reilly Media.
PostgreSQL (2016). About. PostgreSQL. Retrieved from http://www.postgresql.org/about/
Rouse, M. (2016). PostgreSQL definition. Tech Target. Retrieved from http:// whatis.techtarget.com/definition/PostgreSQL