CMSI 486: Welcome to Week 13

This Week's Class Agenda

Presentations — None But The Brave!

  1. Jay & Nguyen & Prochnow
  2. Derham & Ochsner & Wroblewski
  3. Any other brave volunteers?

Database Security Issues Wrap-up

Things to do to Make the Database Secure

Now that you have your server machine scanned and hardened, there are a good many things to be done that will help secure your database at the database level. Some of these are mechanisms, and some are policy-level. In either case, security of your database in today's environment is not really optional. Skip these activities at your own peril! Since most organizations are facing nearly exponential growth in the amount of information and data they must continuously manage and protect to ensure organizational success, it is critical to spend the resources to ensure that the database is secure. Many cybercriminals are going after the database because that is where the sensitive information resides. Someone who is looking to steal credit card information or personal identities will not be interested in a simple DOS attack. With so much at potential risk, the people who have control over the resources MUST secure the database, and must assume the role of stewards of the data to ensure that business operations are not threatened.

Towards that end, here are a few things that are considered best practices that can assist the DBA of the organization to maintain acceptable levels of database security at the database application level:

  1. Keep the database on a server that is separate from the web server: Instead, install the database on a separate server, located behind a firewall. Yes, this is a bit more complicated to administer and maintain, but the security benefits FAR outweigh the additional resources that are needed. Having the database and the web server on the same box means that an attacker only needs to crack ONE administrator-level password to have access to everything.
  2. Encrypt stored files and backups: any files that have value to you will have value to an attacker. If these files are stored on the application server or the database server you should encrypt them. Unencrypted files can provide the keys to the city for all your data to be made available to an attacker or worse, to the entire Internet. Don't forget that people in the organization who once were trusted may change their minds and decide to do things with malicious intent. Encryption is doubly important if your organization is subject to additional rules or constraints, such as HIPAA, SOX, DoD, or other alphabet-name entities. The lesson is, encrypt any files that have value to the organization, since anything that YOU value the bad guys will value, too.
  3. Use a Web Application Firewall (WAF): All web applications are available to customers/constituents – as well as attackers – 24/7/365. For this reason, the traditional IT security systems, such as firewalls or IDS/IPS, may be unable to guard against these attacks or do not offer comprehensive protection. Web Application Firewalls filter, monitor, and block HTTP traffic for web applications, which is different from a regular firewall because it can filter the content of specific web applications. By inspecting HTTP traffic, it can prevent attacks from exploiting most security flaws in a web application.
  4. Keep Patches Current: Websites that use third-party or COTS software such as plug-ins are more susceptible to an exploit than those that have been patched with current software updates. Keep patches current to the most recent releases, when possible. This does NOT mean you need to turn on all your Windows Updates so that you get the update for the Unicode currency symbol for the Zloty, which you'll never use. It DOES mean make sure that if a patch comes down from a vendor, evaluate it and apply it if it makes sense. There is a handy browser add-on called Qualys that can help.
  5. Enable Security Controls: Most DBMSs enable security controls by default, but DBAs should still always check the security settings to make sure the stuff is turned on and configured properly. Remember that organizations may rely on a web developer to create a secure system, but the DBA is the captain of the ship for ensuring that security is maintained on an on-going basis. Be sure to enable security controls on allem> databases and do not assume that this is properly set up by default.
  6. Check user/client workstations: If users are allowed to have restricted data on their workstatins, these workstations must meet minimum security requirements, and the workstation should be protected by preventative measures such as locked screen savers, individual account authentication, encrypted data, USB port disabling, encrypted e-mail systems, and a policy which includes deletion of restricted data that is no longer needed.
  7. Database Roles, Permissions, and Reporting: The DBA creates one or more specific roles in the system. Each role has a specific set of privileges or accesses assigned. Users can then be assigned to one or more of these roles to allow access to the data which they need to do their work [least privilege principle]. Strong passwords are enforced, and are required to be changed on a periodic basis. Accounts should be locked out after a specific number of authentication failures, requiring a DBA to unlock them. Only the DBA should have permission to grant or remove any privileges associated with user accounts; *NO* users should be able to "trickle down" permissions, ehter to their own account, or to any other user account. Reports should be generated periodically for the DBA, showing which users accessed the database, what data was accessed, and the date and time of that access. Also verify that the DBA is someone who is trustworthy, possibly even separating the roles of DBA and database security administrator to separate people.
  8. Database Auditing: All accesses to the database should be logged and tracked, and the logs should be retained for at least a year. The logs should be reviewed periodically by someone knowledgeable in the database operations and intended usage, and a mechanism should be in place to highlight anything questionable that is uncovered. Consider restricting access to the most valuable information that you store on an as-needed basis. Report attempts to access this information whether successful or not. Set alarms within the database that go off if anyone tries to access information in the database that is not pertinent to their role or position, so that you can question their motives.
  9. Database Backup and Recovery: Procedures and policies should be in place [and enforced] to ensure that a comprehensive backup process is in place. Step-by-step instructions should be provided for backing up the database, including responsible parties for all related activities. Further, it is not enough to simply back up the data; there also needs to be a procedure for restoring the data, and the restore process should be documented in a step-wise way and should be tested at least once a year to ensure it is kept current and that related personnel know how to implement it. Verify that the plan includes enough granularity for restoring the database to its fully working state, including the hardware, in case there is a catastrophic failure or natural disaster.
  10. Maintain One Version of the Truth: Assume that all of the off-line copies of the data are stale as soon as they are written. Don't let users or DBAs store any data locally on laptops or other non-secured assets, and ensure that the on-line database is the one true version of the data at all times.

Some General Links for Further Exploration

Securing SQL Server

Securing MySQL

Checklist: Securing Your Database Server

Ten Most Wanted

What Students Need to Know

McAfee Data Center Security Suite

McAfee Vulnerability Manager for Databases

Securing Mongo

Several interesting things crop up when you look through the section of the Mongo book on Security [See chapter 20]. For one thing, we are told NOT to set up publicly addressable MongoDB servers. In fact, a quick read through the Mongo manual starting/stopping section [chapter 20] has several interesting paragraphs:

Backing up as single server installation of MongoDB is as easy as making a copy of the /data/db directory where the data is stored. If there are replicated sets or clusters that need backing up, there are more involved ways to do those things, but let's keep this part short.

Other than that, there isn't a whole lot of information in the MongDB book. However, on the mongo website, there is a Security Checklist which has the following items:

Securing Neo4J

There are a couple of things to note about Neo when setting up security. First, think about the actual use that the database will be filling. If it is a toy or small-scale database on a single box with no outside users, and no connection directly to the Internet, you may not need anything other than the default. At the other end of the scale, you might have hundreds or thousands of users who access your data from the Internet. This latter situation fairly screams for as much security as you can muster. The second scenario also will require that you set up a high availability cluster also called an HA-cluster.

Important things to note [different on windows, but you guys all have macs, right?]; on mac, the conf directory is under the installation folder/diirectory where neo was installed. On Windows, it's in your hidden AppData folder under your user account:

The first thing to do to ensure your data is secure is to set up a backup plan. You've heard me speak at some length of the different types of backup, full, incremental, disaster, daily, and so on. Regardless of the type of backup you use, you should have some kind of plan in place. For Neo, you must first set up the configuration parameter enable_online_backup=true which will make the backup service available on the default backup port of 6362. You can use any port you wish, as long as you specify which port in the parameter. For example, you can use port 9876 by specifying enable_online_backup=port=9876. At that point, backup is done with a simple command:

<running mode>://<host>[:port]{,<host>[:port]*}

the running mode is defined as either single for non-HA clusters, or ha for HA clusters.

Next, here are some standard configuration items that should be decided upon and configured:

Neo4J does not enforce security on the data level by default. This is something to be aware of when you install the application. You should also know this for use in any project demonstrations, since questions of the security of the database are a hot topic and are ripe for questions. Not only that, but it's just good sense to ensure that the data is properly secured.

Securing Access

There are several things that should be done for security. Here is a checklist, with links to the relevant sections of the Neo4J operations manual:

  1. Deploy Neo4j on safe servers in safe networks:
    1. Use subnets and firewalls.
    2. Only open up necessary ports.
      For a list of relevant ports see Section 3.2, Ports.
    3. Run Neo with a proxy, and limit the access to specific IP addresses, URL patterns, and/or IP address ranges. This method can be used to make different clients from different request sources respond in different ways.
    4. RUn Neo as a non-root user on a port less than 1000 [e.g., port 80], especially on a UNIX/Linux system.
  2. Protect data-at-rest:
    1. Use volume encryption (e.g. Bitlocker)
    2. Manage access to database dumps [(]refer to Section 10.3] and backups [(]refer to Section 6.2]. In particular, ensure that there is no external access to the port specified by the setting dbms.backup.address [(this ]defaults to port 6362]. Failing to protect this port leaves a security hole open by which an unauthorized user can make a copy of the database onto a different machine.
    3. Manage access to data files and transaction logs. Prohibit all operating system access to Neo4j files except as instructed in Section 3.1.3, Permissions.
  3. Protect data in transit by only opening up for encrypted HTTPS
  4. Use SSL certificates issues from a trusted Critificate Authority
  5. Stay on top of any custom extensions you install, to make sure they are patched and up-to-date
  6. Ensure the correct file permissions on the Neo4j files. Only the operating system user that Neo4j runs as should have permissions to those files.
  7. If LOAD CSV is enabled, ensure that it does not allow unauthorized users to import data.
  8. Do not turn off Neo4j authentication.
  9. Survey your neo4j.conf file for ports relating to deprecated functions [(]such as neo4j-shell, controlled by the parameter dbms.shell.port]
  10. Use the latest patch version of Neo4j.

Notes cribbed from: Section 7 of the Neo4J on line manual.