Release Information

Overview

What are the most important facts that a developer should know about the security of this system?

The first thing to understand is how user accounts and permissions are represented inside the application. The logic that builds each screen will be more clear after you understand how the visibility of individual fields is controlled by user permissions.

The most important things for a new developer to keep in mind are:

• We have strict calling conventions in place that prevent "tainted" (possibly malicious) user input from being passed through to the database or echoed out on any page.
• We never write SQL code in our application source code, we always go through LIBRARY-or-STORED-PROCEDURES that enforce security concerns.
• Do not add any executable script to the "scripts" directory without discussing it with PERSON-NAME first.
• The system will use SSL in production but we do our development and testing with SSL disabled.

Please keep in mind that we did not originally consider security when designing this system, and we have been forced to go back and close security holes in ways that may seem unclear. We are trying to design more thorough and consistent security in upcoming releases.

What are the ranked goals for security in this system?

1. Data security
2. Intrusion prevention
3. Abuse prevention
4. Auditability

Security Mechanisms

What physical security mechanisms will be used?

• The servers will be kept on our premises or at a secure data center.
• Servers will be kept in a locked room with door code known only to administrators.
• Servers will be kept in a locked equipment rack.
• The server case itself has a security cable that prevents the case from being opened (so the hard-disk with sensitive data cannot be removed).
• Backup tapes are stored in a locked cabinet in a locked room.

What network security mechanisms will be used?

• A firewall device allows access to only specific network ports (e.g., port 80 for web server access).
• Firewall software allows access to only specific network ports (e.g., port 80 for web server access).
• Only the front-end machines are accessible over the Internet. Other machines in the server cluster communicate over a private LAN only.
• Users can only connect to the server from specific ranges of IP-address (e.g., computers on company-owned subnets).
• Certain users (e.g., administrators) can only connect from specific ranges of IP-addresses.
• All network communication takes place over a virtual private network (VPN) that is encrypted and not accessible to outsiders.
• All network communication takes place over a LAN that does not have any connections to the Internet or unsecured wireless networks.

What operating system security will be used?

• We have selected an operating system that has strong security that we know how to use.
• Operating system user accounts will never be created on the servers, other than those accounts needed by the application itself.
• Different components in the application execute as different operating system users, have only the least possible privileges, and may only access the particular files needed by that component.
• Operating system permissions on files and directories are set to prevent undesired access or modification.
• Intrusion detection software is used on the server to detect any modifications made by hackers.
• The operating system and key executables are stored on a disk that is mounted read-only and cannot be modified without a reboot into stand-alone mode.
• Certain critical scripts can only be run from the console, not remotely.
• Administrators monitor security mailing lists for announcements of security holes in any components that we use. Security patches and upgrades will be applied quickly.
• Data on disks and backup tapes is stored using an encrypted file system so that the data is protected even if the media itself is stolen or somehow accessed.

What application security mechanisms will be used?

• Values input into every field are validated before use. Unvalidated input variables are considered "tainted" and cannot be passed into lower-level functions.
• Usernames and passwords are required for access.
• Passwords are stored in an encrypted format.
• We verify all user email addresses to prevent abuse.
• We use a "Turing test" to prevent mass-creation of fraudulent accounts.
• The quality of passwords is checked. E.g., minimum length, dictionary words, commonly used passwords, same as username.
• Each user must have a certificate file on his/her client machine before connecting to the server.
• Each user must have physical security token. E.g., hasp, dongle, smart-card, or fingerprint reader.
• Users are given roles that define their permissions. Those roles are:
  • Guest: Visitor to the site is not logged in, no permissions to change anything
  • Guest: Visitor to the site is not logged in, can post messages anonymously
  • Registered-User: User is logged in, has permissions for X, Y, and Z
  • Administrator: Permission to change anything, even on behalf of other regular users
• Each action (information access or update) requires that the user has a role with proper permissions.
• Compromised or abused accounts can be quickly detected and disabled by administrators.
• Administrators can review user permissions.
• Administrators can audit all accesses and updates.
• All communications with the user are encrypted. E.g., SSL.
• Some communications with the user (e.g., the username and password) are encrypted (e.g., SSL).
• Sessions are tied to a particular client IP-address so that stolen cookies cannot be used by third parties.
• Session cookies are long, random strings that cannot be guessed.
• Sessions time-out so that unattended terminals are less likely to be abused.
• Certain critical operations prompt the user to re-enter his/her password 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.
• Sensitive data, such as credit card numbers, are processed but not retained in any database or file.
• The data access layer is responsible for preventing SQL injection attacks. I.e., hackers attempting to enter SQL statements through application UI fields.
• The data access layer allows read-only connections, which will be used for most requests, as well as distinct read-write connections used only for requests that are designed to update the database.
• The HTML generation layer is responsible for preventing cross-site-scripting (XSS) attacks: it escapes any markup characters in user-entered text before echoing it out to any page.
• The application prevents CSRF (Cross-Site Request Forgery) attacks. It does this by performing commands only after a POST, and checking that the referring page was, in fact, served by the system. The referring page can be validated by the HTTP-Referrer or by a unique token in a hidden form field.

Security Checklist

Protection of data: To what extent has this been achieved?

It has been achieved. The system uses very simple and effective controls that are clearly adequate. There are no other ways to access or update the data.

We think we are doing well. The "front door" to the data seems secure. We are not sure if there are any "back door" ways to access or update the data.

We should be OK, but we have not reviewed all data access features for security yet. That will be done by MILESTONE.

We have known data security problems. They are assigned to a developer and are being tracked.

Prevention of intrusion: To what extent has this been achieved?

It has been achieved. We can prove that there are only a few, limited ways to gain access to the server, and all of them are well protected.

We think we are doing well. We have proactively done all the standard steps to secure the system.

We should be OK. We have not audited the server security yet, but we don't think that we have done anything to open any holes. An audit will be done by MILESTONE.

We have known security openings that could allow intrusion. They are assigned to a developer and are being tracked.

Prevention of abuse: To what extent has this been achieved?

It has been achieved. The users are trusted very little, and we can prove that everything users can possibly do is checked very closely.

We think we are doing well. We have gone down a list of common types of abuse and discussed how they can be prevented in this system.

We should be OK, but we have not reviewed the system for potential abuse yet. That will be done by MILESTONE.

We have known opportunities for abuse. They are assigned to a developer and are being tracked.

Accountability/auditing: To what extent has this been achieved?

It has been achieved. We log every detail of all operations, and the logs themselves can not be edited or deleted.

We think we are doing well. Key operations are logged and we think that we are capturing enough information.

We should be OK. We have not made any choices that make it harder to use standard server logs to track down abuse. We will consider the need for more accountability by MILESTONE.

We have known problem where changes cannot be audited after they occur. These problems are assigned to a developer and are being tracked.

Have these security mechanisms been communicated to the development team and other stakeholders?

Yes, everyone understands. Feedback is welcome.

Yes, this security design document is posted on our project website.

No, this is a risk that is noted in the risk management worksheet.