« Back

gateways security and accounting

Security and Accounting for XSEDE gateways

All gateway developers will want to build their gateways using best practices for portal and web application development. General suggestions are listed on the Science Gateways for Developers page under The Role of the Gateway Developer: Best Practices. In addition, XSEDE has specific security and accounting requirements and recommendations for connecting to its resources to optimize your gateway for prevention and triage of security incidents or inadvertent misuse. In addition, accurate accounting practices will provide statistics to help justify requests by the gateway PI subsequent proposals.

Security and Accounting Requirements and Recommendations

What to Do in a Security Incident

Whether a threat is confirmed or suspected, quick action and immediate communication with XSEDE Security Working Group is essential. help at xsede dot org; SDL: correct number?1-866-907-2383

Make Use of Community Accounts

Community Accounts are described at length on the main page of the developers section; they are the most common account strategy for XSEDE Science Gateways. Community Accounts present specific security and accounting challenges for the gateway developer, because many end users share access to XSEDE resources through the shared account. Consequently, the developer will typically want to restrict privileges so that it can run a limited set of applications.

To distinguish one gateway user from another, the gateway developer has to institute a user registry and gateway authentication mechanism. A gateway may wish to distinguish between identification mechanisms and capabilities for different types of users. For example, lightweight identification mechanisms may be appropriate for K-12 users making small demonstration runs. More substantial identification and justification for resources may be required for senior researchers using large fractions of a gateway allocation. XSEDE Resource Provider sites may choose to restrict community accounts in a variety of ways, for example chroot jails or non-shell, role-based accounts which allow the execution of only selected commands or commands located in specific directories. Some of the techniques for managing community accounts are described below.

Institute a User Registry

Science gateways must implement a user registry that contains contact information for all users accessing XSEDE resources through the gateway.

Gateways may provide access to their XSEDE allocated resources for demonstration or class accounts. In cases such as these, capabilities would be very limited.

Collect resource usage information for each registered user.

Provide the ability to restrict job submissions on a per user basis. This is optional, but can protect the gateway from the shut down of an entire community account in the event of a security incident. The restriction interface is described at SDL: huh? [X, given a problem local jobid need to stop all jobs from a user who submitted the problem job or jobs].

SDL: confusing. No bullet points above. Also still relevant?For jobs submitted via Globus GRAM, the capabilities in the second and third bullets above can be provided through GRAM auditing, http://www.xsedeforum.org/mediawiki/index.php?title=TeraGrid_Science_Gateways_Primer#GRAM_Audit_Capabilities.

Identification of researchers who have benefited from the services offered by the Gateway will be a fundamental part of future requests requesting XSEDE resources and may also be useful to the Gateway's own funding efforts.

Sample frameworks for gateway user management are included [here].

Devise a Credential Strategy

Gateways require X.509 credentials for accessing XSEDE resources securely. Developers need to plan a strategy to fit their credential management scenarios. Users access XSEDE resources via science gateways using either individual credentials (i.e., issued to a single user who is known to the XSEDE Central Database) or community credentials (i.e., issued to the gateway which is responsible for per-user tracking). Individual credentials allow XSEDE resource providers (RPs) to track per-person resource usage using standard account-based techniques, based on the XSEDE allocations process. Community credentials provide a more scalable approach, allowing user registration to be outsourced to the gateway, but XSEDE RPs still require the ability to track per-person resource usage for accounting and security reasons.

Gateways can combine both approaches, allowing registered XSEDE users to access resources with their individual credentials and others to access resources via a community credential. For more about scenarios and strategies, see the Science Gateway Credential Management in the XSEDE Wiki.

Maintain An Audit Trail: Keep a Gateway Log

Keeping an audit trail enables traceback to a user engaged in abusive or suspicious activity or a serious security breach. The audit trail consists of a log of all user login and job activity. The audit trail is now being managed by attribute-based authentication, which sends expanded information, including unique user identifiers, in job submission records. These records will be recorded in the XSEDE Central Database (TGCDB) and available for individual management of security. See Attribute-based Authentication below.

Log Authentication and Authorization Activity

All login activity, including attempts, successful logins, and further authorization should include the following data:

  • the requesting IP address
  • date stamp (Universal Time Code)
  • username

Map User Activity to Jobs Run on XSEDE Resources

With the adoption of attribute-based authentication, it will no longer be necessary to maintain job information; however, it may be helpful in policing your gateway in case of an infraction in security.

GRAM jobs:

  • GRAM job handle (which usually looks like https://<execHost>:49xxx//xxxxx/xxxxxxxx) for each job submitted by a gateway user for Globus-based gateways. The mapping between this job handle and the scheduler local jobID on the XSEDE compute resource will be provided via an auditing Web Service
  • RSL for each job for GRAM jobs.

Non-GRAM job submissions:

  • the remote command(s) executed via SSH, scripts, Web Services, or some other method to initiate a job on a XSEDE compute resource.
  • scheduler local jobID to gateway user mapping

For both GRAM and non-GRAM:

  • XSEDE resource to which the job was submitted.
  • Application(s) launched (especially for canned apps).
  • Timestamp for each job launch and termination.

Use Attribute-based Authentication (GridShib/SAML) in Community Credentials

Attribute-based authentication is required for all gateways submitting jobs via a community account. This fulfills the NSF requirement that XSEDE provide the number of unique end users running jobs on the systems on a quarterly basis.

For gateways submitting jobs using gsi-ssh, a script is run after each job submission that attaches attributes to that job. More information on this process is available at:

http://www.xsedeforum.org/mediawiki/index.php?title=Gateway-Submit-Attributes.

Gateways using Globus for job submission will need to install the GridShib SAML Tools package and use the XSEDE Science Gateway SAML Extension to bind a SAML token to a proxy certificate that is signed by a gateway's community credential. This software is available at:

http://www.xsedeforum.org/mediawiki/index.php?title=Science_Gateway_Credential_with_Attributes.

Safeguard and Validate Programs, Scripts, and Input

Developers will want to consider the security of codes running on XSEDE resources. To the extent possible, gateways must implement safeguards (to be determined jointly with the XSEDE gateways and Security Working Groups) to protect against intentional or unintentional abuse by programs, scripts, and input. For example, input entered through a web form cause must not cause buffer overflows when a code is run using the resulting input files. Gateways should not let anonymous users upload executable files.

Perform Risk and Vulnerability Assessment

In March, 2008, the TeraGrid Security Working Group began a Gateway Risk Assessment Survey to help determine the baseline level of security for the gateways, and to document the kinds of questions that need to be asked for ongoing security evaluation. It was designed to provide the information needed by XSEDE for incident prevention and response and to evaluate security threats, to suggest possible mitigations, and to determine whether the unmitigated risk can be accepted as a cost of doing business.

Gateways may want to participate in a risk and vulnerability assessment in collaboration with the XSEDE Security Working Group annually. See the Vulnerability Assessment spreadsheet from the Wiki. SDL: correct name & email?E-mail questions and suggestions to Jim Rome, jar at ornl dot gov and Jeff Rosendale, jeffr at ncsa dot uiuc dot edu

Protect Portal Passwords Locally and Over the Network

Gateways should implement a strong password enforcement mechanism for its users. They must also use SSL or some other encryption mechanism to protect gateway user passwords from being transmitted in the clear.

Collect Accounting (and Other) Statistics

XSEDE must report several important metrics about the gateways it supports:

Gateways must record each gateway user's total SU usage. This will be useful both for final reports for your project, requests for future allocations, and for the Security or Accounting Working Groups should they need to investigate abuse or overuse. Once your gateway implements attribute-based authentication, this will be done automatically by XSEDE.

Science successes may be more challenging for a gateway to collect because of the disparate nature of the user community. Nevertheless, science success due to the use of the gateway are important, both for XSEDE resource requests and likely for gateway funding requests as well. Published papers provide a supporting statistic.

  • Each gateway user's total SU Usage
  • SDL: Is this a metric? Science success stories (annually)
  • Number of end gateway users (quarterly)

SDL: Are we transferring "How to Write a Winning…" doc? Successful tips for gateway PIs for requesting resources through the NSF allocation process are described at How to Write a Winning Gateway Proposal. Justification of the resources requested, papers published because of the use of the resources are key factors in a successful proposal.