System Assurance through Memory and Shared Resource Protection - Introduction

This is the introduction to my new paper, System Assurance through Memory and Shared Resource Protection. Like previous ones, I will be posting it in pieces with the last page having a link to the paper.

Regardless of the operating system, architecture, or purpose, general purpose computing devices have one unquestioned constant: instructions and the data they operate on are available in primary storage. While instructions and initial data can be permanently fixed in read only memory, data being interacted with must be writable and is typically volatile, random access memory: RAM. (Jessup, Valacich & Wade, 2003) Whenever an interaction involves reading information there is a potential for concerns about the confidentiality of the data and the reliability of the read is dependent on the data integrity. Writing interactions present potential threats to data integrity, and both reading and writing actions are dependent on the availability of the data source. This statements are true and applicable when the interactions in question are performed with reference to computer memory; thus memory needs protection to ensure the confidentiality, integrity, and availability of the system it resides within.

Operating systems, as massively complex pieces of software, are simultaneously dependent on the integrity of system memory and responsible for the protection of that same memory. To achieve this state of existing in the same memory that it is protecting, the operating system utilizes the privilege features provided by the hardware to allocate sections of the memory to by only accessible by code running in a privileged context: the kernel. (Vacca, 2009) Remaining sections of memory are left readable, writable, or both by code running without being in a privileged context: userspace.

Abstracting the limitations and layout of physical RAM away from the memory accesses by software additionally protects the memory state of both kernel and userspace code. This model of virtual memory utilizes secondary storage, such as a hard disk, to store data that running code gets to treat as being in memory even if the amount of memory being used exceeds the capacity of the physical RAM. (Jessup et al., 2003) Implementing such abstraction requires dedicated, specialized code in the kernel which can perform actions while running such as permission checking. While the abstraction code is running it is also utilized to provide significant additions to security scheme protecting system memory.

A third related, but not entirely limited to memory, system protection is the polyinstantiation of shared resources. Polyinstantiation is the generation of a separate instance of an accessed resource for the accessor. A common, necessary occurrence in multilevel databases, poly-instantiated records are records that share a supposedly unique key. (Jajodia & Sandhu, 1994) Virtual memory, as a model, is itself an example of polyinstantiation of the addressable memory space.

---

Jajodia, S., & Sandhu, R. (1994). Solutions to the polyinstantiation problem. GEORGE MASON UNIV FAIRFAX VA.

Jessup, L. M., Valacich, J. S., & Wade, M. (2003). Information systems today. Upper Saddle River, NJ, USA: Prentice Hall.

Vacca, J. R. (2009). Computer and Information Security Handbook. Burlington, MA: Morgan Kaufman

Web Database Vulnerabilities

What specific vulnerabilities affect Web enabled databases? What can be done to prevent them from happening?

Meier, from Microsoft, claims that the main threats to a database server are SQL injection, Network eavesdropping, Unauthorized server access, and Password cracking. (Meier, 2003) Since we are focusing on web databases, the relevant two threats are SQL injection and network eavesdropping. The other two are primarily local threats, assuming that the password cracking is hash cracking.

Network eavesdropping is a concern if the database is being accessed over an unencrypted protocol, such as HTTP, since the communicated data is visible in the traffic. This causes threats to the confidentiality of the data being read from or written to the database as well as threats to the integrity of the data. If the network connection is being manipulated by a man-in-the-middle attacker, they could modify requested database writes or the returned database reads. (Kabay, Holden, & Walsh, 2002) The ultimate threat of network eavesdropping is if credentials are being passed in the clear because that risks turning over complete database control to the attacker. (Meier, 2003)

Eavesdropping is most easily addressed by forcing all traffic to be encrypted, like using HTTPS instead of HTTP for the web connections.

SQL injection, or attacking “Applications that construct queries on the fly can be fooled into constructing improper queries” (Gertz & RosenThal, 2006), is where “the attacker exploits vulnerabilities in your application's input validation and data access code to run arbitrary commands in the database using the security context of the Web application.” (Meier, 2003) This vulnerability occurs regularly, despite its severity, because the quickest, easiest way to generate a SQL query is through normal string building operations can concatenating in the search specific values. Often these values have been received directly from the outside and may have been maliciously crafted, but not validated or escaped. Thus, special characters and keywords have special meaning to the database and get executed instead of just searched for.

All input data should be limited, checked for validity, and sanitized of anything that may be viewed as code. This can mean escaping special characters or stripping them out of the string entirely. Limiting data to expected formats helps too, such as a search for numerical data should be checked that it only contains numerical characters. SQL queries should use type safe parameters, as this prevents string building and mismatched data types as well as guaranteeing that data passed in is treated as data and not executable statements. Lastly, the web facing account should have the least privileges possible. If the web interface is only for reading then the account should not even have write privileges. Tables that will not be queried through the web should not be readable by that account either. (Meier, 2003)

---

Gertz, M., Rosenthal, A. (2006) Database Security. In H. Bidgoli (Ed.), Handbook of information security, volume 3. "Database Security Mechanisms and Models" p. 164. New York, NY: John Wiley & Sons, Inc.

Kabay, M., Holden, D., Walsh, M. (2002). Operations Security and Production Controls. In Bosworth et al (Eds.), Computer security handbook. New York, NY: John Wiley & Sons, Inc.

Meier, J. D. (2003). Improving web application security: threats and countermeasures. O'Reilly Media, Inc..

Necessity of Securing Database Config

There are many problems with securing enterprise databases, far more than the IT industry would care to acknowledge. Research and discuss one particular database security issue. How can this problem be addressed?

One significant database security issue, according to McGowan, Bardin, and McDonald, is that “With any complex software system, poor configuration practices cause vulnerability.” (2009, p171) They, correctly, assert that this is the case with database systems. Oracle databases are a good example of the complexity and how poor configuration can occur. Configurable options include accounts, authentication modes, options and products, schemas, and passwords. (Oracle, 2012)

For instance, features of user accounts which are configurable include limits on failed login attempts, password lifetime, password reuse restrictions, number of concurrent sessions, and idle timeout. (Baccam, 2010) Preventing remote password brute force attempts, making sure to expire passwords, and making sure an idle session isn’t left available for hijacking all can be implemented through this type of options.

Another important configuration to be aware of it being sure to maintain audit trails and transaction records. Baccam’s paper details exact configuration options that should be enabled for security: settings like “AUDIT_SYS_OPERATIONS (Should be set to TRUE.)” and “AUDIT_TRAIL (Avoid FALSE or NONE settings.)” (2010, p5)

Default accounts, especially ones with static or predictable passwords, need to be addressed. It is the fourth item on Oracles Guidelines for Securing a Database Installation and Configuration.

1. Before you begin an Oracle Database installation on UNIX systems, ensure that the umask value is 022 for the Oracle owner account.
2. Install only what is required.
3. During installation, when you are prompted for a password, create a secure password.
4. Immediately after installation, lock and expire default user accounts.

(Oracle, 2012)

Limiting the install will be familiar to anyone who has tried to harden a server, where all unnecessary services running present additional potential attack vectors. Oracle mentions that the installation media defaults to installing multiple products and ones not required should be uninstalled or not installed by way of the custom choice. Similarly sample schemas are included for helping set up test databases. These should not be used for production machines. (Oracle, 2012)

---

Baccam, T. (2010). Oracle Database Security: What to Look for and Where to Secure. SANS Analyst Program. Retrieved from https://www.sans.org/reading-room/analysts-program/oraclewhitepaper-201004

McGowan, J., Bardin, J., & McDonald, J. (2009). Storage security. In Vacca, J. R. (Ed.), Computer and information security handbook. Boston, MA: Morgan Kaufmann Publishers.

Oracle. (2012). Keeping Your Oracle Database Secure. Oracle® Database Security Guide. Retrieved from http://docs.oracle.com/cd/B28359_01/network.111/b28531/guidelines.htm#i1007892

Smartcards: Solving the authentication problem

Discuss ways in which the use of strong authentication can be designed to be "user friendly" without compromising its effectiveness.

In 1989 Ken Fifield was already writing about the value of plastic cards containing microprocessors to be used for digital signatures and strong authentication. (Fifield, 1989) Jumping forward to today, we still see it as a reasonable solution because, as Bruce Schneier (2005) put it “We're all good at securing small pieces of paper.” Protecting a small, plastic card? We do this all the time. Our credit cards, our driver's license: these items are almost always on our person or in a known protected location. If an organization is implementing physical security then there is probably even already a small plastic card that the employees carry with them to access the building and swear who they are.

A picture identification badge is being used to authenticate the wearer into a space when a human guard validates the authenticity of the badge and that the wearer matches the picture. Digitally, the same thing can be accomplished with the same card, if it is a smart card. The module this week explicitly points out that “single smart card can serve as an employee ID badge, building access card, PKI credential store, and application password provider.” (UMUC, 2001) The PKI credential store what really allows the smart card to shine because that provides the card holder the ability to easily provide digital signatures on their work and communications and also easily decrypt information sent to them. Authenticated access to documents is free if the infrastructure can provide everything PKI encrypted, only the intended user can decrypt the documents, even if they end up in the hands of an un-authenticated attacker.

---

Fifield, K. J. (1989). Smartcards outsmart computer crime. Computers & Security, 8(3), 247-255.

Schneier, B. (June 17, 2005) Write Down Your Password. Schneier on Security Retrieved from: https://www.schneier.com/blog/archives/2005/06/write_down_your.html

UMUC. (2011) Authentication , CSEC-630 – Module 4. Retrieved from: http://tychousa11.umuc.edu/cgi-bin/id/FlashSubmit/fs_link.pl?class=1309:CSEC630:9050&fs_project_id=384&xload&cType=wbc&tmpl=CSECfixed&moduleSelected=csec630_04

Defending once authenticated: Time outs

After users are authenticated, what measures can be employed in order to maintain security when users are away from their computers?

Although it clashes with the desired convenience, or “user friendliness”, of the system and common and reliable security measure is to limited the authenticated session duration through a time out. Time outs assist in maintaining security because they cause authentication artifacts to stop assisting intruders in the event of a compromise. The replay attack on Kerberos discussed in our module demonstrates the value of a time out, because the “Kerberos authenticators include time stamps so that authenticators are valid only for a short period of time.” Attempting to resend an authenticator after that time window has expired will fail to provide the excepted authenticated action. (UMUC, 2011)

The time out protection philosophy is regularly seen in the protection of the authenticated user on desktop operating systems. This the protection being implemented when the a password protected screen saver or other lock-out style screen locks are used. Groves writes that “In the event that you are dragged away from your machine having the screen saver activate after a set period of time will help to prevent unauthorized access to the console.” (2003, pp. 11) Once configured, this protection assures that the authenticated user does not have to actively protect their session, merely not interacting with the computer for the duration of the time out will lock it down. They do have to re-authenticate afterwards, but an attacker who has accessed the system will be unable to act as them.

---

Groves, Z. (2003). A Best Practices Guide To Secure a Windows XP Professional Installation. SANS Penetration Testing Retrieved from: http://cyber-defense.sans.org/resources/papers/gsec/practices-guide-secure-windowsr-xp-professional-installation-105157

UMUC. (2011) Authentication , CSEC-630 – Module 4. Retrieved from: http://tychousa11.umuc.edu/cgi-bin/id/FlashSubmit/fs_link.pl?class=1309:CSEC630:9050&fs_project_id=384&xload&cType=wbc&tmpl=CSECfixed&moduleSelected=csec630_04