What are the most important facts that a developer should know
about the security of this system?
At some laboratories one scientist's work in progress is confidential from other users.
Sometimes scientists collaborate on projects, which are confidential from others. One scientist may be a member of several such workgroups, e.g. as a supervisor of the research.
Some laboratories take commercial work from drug companies, and the contracts require confidentiality.
Some laboratories want to offer remote read access to the LIMS - including customers being able to review data that is confidential to themselves.
Some laboratories want remote write access to the LIMS.
Intrusion prevention measures are required, corresponding to the state of the art for web applications.
Some laboratories have genes for dangerous proteins, and in future their LIMS may be able to control robots remotely. Starting an experiment should require a safety assessment, and it should be easy to demonstrate that no dangerous experiment can be begun by remote access.
What are the ranked goals for security in this system?
How are security responsibilities assigned to components?
The data access layer will be responsible for preventing SQL injection attacks.
The data access layer allow read-only connections, which will be used for most requests, as well as write connections for requests that update the database.
The HTML generation layer will be responsible for preventing XSS attacks.
The HTML generation layer will be responsible for preventing CSRF attacks.
It will do this by performing updates to the database only after a POST,
and checking that the referring page was served by the system for every POST.
Browsers that do not report HTTP-Referer will not be supported.
What other application security mechanisms will be used?
Values input into every field are validated before use
Usernames and passwords are required for access
Passwords are stored encrypted
Users can be given roles that define their permissions.
Each action (information display or change) requires that the
user has a role with proper permissions
Compromised or abused accounts can be quickly disabled by administrators.
Administrators can review user permissions
Administrators can audit all accesses and changes (later)
Sessions are tied to a particular client IP-address so that
stolen cookies cannot be used.
It is not considered necessary to support networks
in which more than one proxy can be used for a single session.
If this becomes necessary, we will require the users
to define a list of "trusted proxies" during installation.
Session cookies are long random strings that cannot be
guessed.
Sessions time out so that unattended terminals cannot be
abused.
Actions that seem to destroy data actually move it to a place
where it can still be reviewed by administrators.
What physical security mechanisms will be used?
TBD
What network security mechanisms will be used?
Some labs may use a firewall to prevent all external access.
Some labsmay chose to use HTTPS for access outside the firewall
Later we will offer access control using grid certificates as an alternative to HTTPS
If a lab's LIMS is so large it needs a separate database server, we recommend it communicate over a private LAN, or through an encrypted connection.
We recommend that users can only connect to the server from specific ranges of
IP-address (e.g., university-owned computers in networks on
campus).
We also recommend that administrators and ids for safety roles can only connect from
specific ranges of IP-addresses.
What operating system security will be used?
Operating system user accounts will never be created on the
servers, other than those needed by the application itself.
Different components in the application execute as different
operating system users, and only have access to particular files.
Operating system permissions on files and directories are set
to prevent undesired access or modification.
In the project continuity plan, we will ensure that administrators will monitor security mailing lists for
announcements of security holes in any components that we use and
security patches and upgrades will be applied quickly.
Security Checklist
Protection of data: To what extent has this been achieved?
TBD
Prevention of intrusion: To what extent has this been achieved?
TBD
Prevention of abuse: To what extent has this been achieved?
TBD
Accountability/auditing: To what extent has this been achieved?
TBD
Have these security mechanisms been communicated to the
development team and other stakeholders?