7.1 KiB
7.1 KiB
<html>
<head>
</head>
Overview
Project Plan
Workflows
Current
<!-- Markdown content here -->
<h1 id="user-content-designdesignhtmlnbspgtnbspsecurity" dir="auto"><a href="/Suborbital-Systems/ReadySetGit/src/commit/757571a6b5d5960537315aa5f70c98e5d4ae7eef/design.html">Design</a> > Security</h1>
<hr>
<h5 id="user-content-project" dir="auto">Project:</h5>
<p dir="auto">::PROJECTNAME</p>
<h5 id="user-content-internal-release-number" dir="auto">Internal Release Number:</h5>
<p dir="auto">::X.Y.Z</p>
<h5 id="user-content-related-documents" dir="auto">Related Documents:</h5>
<ul dir="auto">
<li>::LINKS TO RELEVANT STANDARDS</li>
<li>::LINKS TO OTHER DOCUMENTS</li>
</ul>
<hr>
<h3 id="user-content-overview" dir="auto">Overview</h3>
<p dir="auto"><em>TODO: Answer the questions below to help you design needed security
features. Some example text is provided. Add or delete text as needed.</em></p>
<h4 id="user-content-what-are-the-most-important-facts-that-a-developer-should-know-about-the-security-of-this-system" dir="auto">What are the most important facts that a developer should know about the security of this system?</h4>
<p dir="auto">::PARAGRAPH OR BULLETS</p>
<h4 id="user-content-what-are-the-ranked-goals-for-security-in-this-system" dir="auto">What are the ranked goals for security in this system?</h4>
<ol dir="auto">
<li>::<a href="/Suborbital-Systems/ReadySetGit/src/commit/757571a6b5d5960537315aa5f70c98e5d4ae7eef/glossary-std.html#data_security">Data security</a></li>
<li>::<a href="/Suborbital-Systems/ReadySetGit/src/commit/757571a6b5d5960537315aa5f70c98e5d4ae7eef/glossary-std.html#intrusion_prevention">Intrusion prevention</a></li>
<li>::<a href="/Suborbital-Systems/ReadySetGit/src/commit/757571a6b5d5960537315aa5f70c98e5d4ae7eef/glossary-std.html#abuse_prevention">Abuse prevention</a></li>
<li>::<a href="/Suborbital-Systems/ReadySetGit/src/commit/757571a6b5d5960537315aa5f70c98e5d4ae7eef/glossary-std.html#auditability">Auditability</a></li>
</ol>
<h3 id="user-content-security-mechanisms" dir="auto">Security Mechanisms</h3>
<p dir="auto"> </p>
<h4 id="user-content-what-physical-security-mechanisms-will-be-used" dir="auto">What physical security mechanisms will be used?</h4>
<ul dir="auto">
<li>::Servers will be kept in a locked room with door code known only
to administrators.</li>
<li>::Servers will be kept in a locked equipment rack.</li>
<li>::Server case itself has a security cable that prevents the case
from being opened (so the hard-disk with sensitive data cannot
be removed).</li>
<li>::Backup tapes are stored in a locked cabinet in a locked room.</li>
</ul>
<h4 id="user-content-what-network-security-mechanisms-will-be-used" dir="auto">What network security mechanisms will be used?</h4>
<ul dir="auto">
<li>::A firewall device limits access to specific network ports (e.g.,
port 80 for web server access).</li>
<li>::Firewall software limits access to specific network ports (e.g.,
port 80 for web server access).</li>
<li>::Only the front-end machines are accessible over the Internet.
Other machines in the server cluster communicate over a private
LAN only.</li>
<li>::Users can only connect to the server from specific ranges of
IP-address (e.g., university-owned computers in networks
on campus).</li>
<li>::Certain users (e.g., administrators) can only connect from
specific ranges of IP-addresses.</li>
<li>::All network communication takes place over a virtual private
network (VPN) that is encrypted and not accessible to outsiders.</li>
<li>::All network communication takes place over a LAN that does not
have any connections to the Internet.</li>
</ul>
<h4 id="user-content-what-operating-system-security-will-be-used" dir="auto">What operating system security will be used?</h4>
<ul dir="auto">
<li>::Operating system user accounts will never be created on the
servers, other than those needed by the application itself.</li>
<li>::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.</li>
<li>::Operating system permissions on files and directories are set to
prevent undesired access or modification.</li>
<li>::Intrusion detection software will be used on the server to
detect any modifications made by hackers.</li>
<li>::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.</li>
<li>::Data on disks and backup tapes is stored using an encrypted file
system so that the data is protected if the media itself is
stolen or somehow accessed.</li>
</ul>
<h4 id="user-content-what-application-security-mechanisms-will-be-used" dir="auto">What application security mechanisms will be used?</h4>
<ul dir="auto">
<li>::Values input into every field are validated before use</li>
<li>::Usernames and passwords are required for access</li>
<li>::Passwords are stored encrypted</li>
<li>::Verification of user email address</li>
<li>::The quality of passwords is checked</li>
<li>::Users must have certificate files on their client machine before
they can connect to the server</li>
<li>::Users must have physical security tokens (e.g., hasp, dongle,
smartcard, or fingerprint reader)</li>
<li>::Users are given roles that define their permissions. Those roles
are:
<ul dir="auto">
<li>::Guest: Visitor to the site is not logged in, no permissions
to change anything</li>
<li>::Guest: Visitor to the site is not logged in, can post
messages anonymously</li>
<li>::RegisteredUser: User is logged in, has permissions for X, Y,
and Z</li>
<li>::Administrator: Permission to change anything, even on behalf
of other regular users</li>
</ul>
</li>
<li>::Each action (information display or change) requires that the
user has a role with proper permissions</li>
<li>::Compromised or abused accounts can be quickly disabled
by administrators.</li>
<li>::Administrators can review user permissions</li>
<li>::Administrators can audit all accesses and changes</li>
<li>::All communications with the user are encrypted (e.g., SSL)</li>
<li>::Some communications with the user (e.g., the username
and password) are encrypted (e.g., SSL)</li>
<li>::Sessions are tied to a particular client IP-address so that
stolen cookies cannot be used.</li>
<li>::Session cookies are long random strings that cannot be guessed.</li>
<li>::Sessions time out so that unattended terminals cannot be abused.</li>
<li>::Actions that seem to destroy data actually move it to a place
where it can still be reviewed by administrators.</li>
<li>::Sensitive data, such as credit card numbers, are processed but
not retained in any database or file</li>
<li>::The data access layer will be responsible for preventing SQL
injection attacks (i.e., hackers attempting to enter SQL
statements through application UI fields).</li>
<li>::The data access layer will allow read-only connections, which
will be used for most requests, as well as write connections for
requests that update the database.</li>
<li>::The HTML generation layer will be responsible for preventing
cross-site-scripting (XSS) attacks.</li>
<li>::The application will prevent 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-Referrer will not
be supported.</li>
</ul>
<h3 id="user-content-security-checklist" dir="auto">Security Checklist</h3>
<p dir="auto"> </p>
<h4 id="user-content-protection-of-data-to-what-extent-has-this-been-achieved" dir="auto">Protection of data: To what extent has this been achieved?</h4>
<p dir="auto">::2-4 SENTENCES</p>
<h4 id="user-content-prevention-of-intrusion-to-what-extent-has-this-been-achieved" dir="auto">Prevention of intrusion: To what extent has this been achieved?</h4>
<p dir="auto">::2-4 SENTENCES</p>
<h4 id="user-content-prevention-of-abuse-to-what-extent-has-this-been-achieved" dir="auto">Prevention of abuse: To what extent has this been achieved?</h4>
<p dir="auto">::2-4 SENTENCES</p>
<h4 id="user-content-accountabilityauditing-to-what-extent-has-this-been-achieved" dir="auto">Accountability/auditing: To what extent has this been achieved?</h4>
<p dir="auto">::2-4 SENTENCES</p>
<h4 id="user-content-have-these-security-mechanisms-been-communicated-to-the-development-team-and-other-stakeholders" dir="auto">Have these security mechanisms been communicated to the development team and other stakeholders?</h4>
<p dir="auto">::Yes, everyone understands. Feedback is welcome.</p>
<p dir="auto">::No, this is a risk that is noted in the <a href="/Suborbital-Systems/ReadySetGit/src/commit/757571a6b5d5960537315aa5f70c98e5d4ae7eef/plan#risks">Risk
Management</a> section.</p>
<!-- End Markdown content -->
</html>