initial import
This commit is contained in:
198
Design-Security.md
Normal file
198
Design-Security.md
Normal file
@@ -0,0 +1,198 @@
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<meta charset="utf-8"/>
|
||||
<link type="image/png" href="assets/logo.png" rel="icon">
|
||||
<title>ReadySet Markdown</title>
|
||||
</head>
|
||||
<script src="https://www.w3schools.com/lib/w3data.js"></script>
|
||||
<body>
|
||||
|
||||
<topbar style="display:none;">
|
||||
<item><a href="index.html">Overview</a></item>
|
||||
<item><a href="plan.html">Project Plan</a></item>
|
||||
<item><a href="index-all.html">Workflows</a></item>
|
||||
<menu name="Themes"><item><a id="settheme"><b>Current</b></a></item></menu>
|
||||
<toc></toc>
|
||||
</topbar>
|
||||
|
||||
<xmp theme="readable" style="display:none;">
|
||||
<!-- Markdown content here -->
|
||||
|
||||
# [Design](design.html) > Security
|
||||
---
|
||||
|
||||
##### Project:
|
||||
::PROJECTNAME
|
||||
|
||||
##### Internal Release Number:
|
||||
::X.Y.Z
|
||||
|
||||
##### Related Documents:
|
||||
- ::LINKS TO RELEVANT STANDARDS
|
||||
- ::LINKS TO OTHER DOCUMENTS
|
||||
---
|
||||
|
||||
### Overview
|
||||
|
||||
*TODO: Answer the questions below to help you design needed security
|
||||
features. Some example text is provided. Add or delete text as needed.*
|
||||
|
||||
#### What are the most important facts that a developer should know about the security of this system?
|
||||
|
||||
::PARAGRAPH OR BULLETS
|
||||
|
||||
#### What are the ranked goals for security in this system?
|
||||
|
||||
1. ::[Data security](glossary-std.html#data_security)
|
||||
2. ::[Intrusion prevention](glossary-std.html#intrusion_prevention)
|
||||
3. ::[Abuse prevention](glossary-std.html#abuse_prevention)
|
||||
4. ::[Auditability](glossary-std.html#auditability)
|
||||
|
||||
### Security Mechanisms
|
||||
|
||||
|
||||
#### What physical security mechanisms will be used?
|
||||
|
||||
- ::Servers will be kept in a locked room with door code known only
|
||||
to administrators.
|
||||
- ::Servers will be kept in a locked equipment rack.
|
||||
- ::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 limits access to specific network ports (e.g.,
|
||||
port 80 for web server access).
|
||||
- ::Firewall software limits access to 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., university-owned computers in networks
|
||||
on campus).
|
||||
- ::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.
|
||||
|
||||
#### 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, 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 will be used on the server to
|
||||
detect any modifications made by hackers.
|
||||
- ::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.
|
||||
- ::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.
|
||||
|
||||
#### What 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
|
||||
- ::Verification of user email address
|
||||
- ::The quality of passwords is checked
|
||||
- ::Users must have certificate files on their client machine before
|
||||
they can connect to the server
|
||||
- ::Users must have physical security tokens (e.g., hasp, dongle,
|
||||
smartcard, 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
|
||||
- ::RegisteredUser: 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 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
|
||||
- ::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.
|
||||
- ::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.
|
||||
- ::Sensitive data, such as credit card numbers, are processed but
|
||||
not retained in any database or file
|
||||
- ::The data access layer will be responsible for preventing SQL
|
||||
injection attacks (i.e., hackers attempting to enter SQL
|
||||
statements through application UI fields).
|
||||
- ::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.
|
||||
- ::The HTML generation layer will be responsible for preventing
|
||||
cross-site-scripting (XSS) attacks.
|
||||
- ::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.
|
||||
|
||||
### Security Checklist
|
||||
|
||||
|
||||
#### Protection of data: To what extent has this been achieved?
|
||||
|
||||
::2-4 SENTENCES
|
||||
|
||||
#### Prevention of intrusion: To what extent has this been achieved?
|
||||
|
||||
::2-4 SENTENCES
|
||||
|
||||
#### Prevention of abuse: To what extent has this been achieved?
|
||||
|
||||
::2-4 SENTENCES
|
||||
|
||||
#### Accountability/auditing: To what extent has this been achieved?
|
||||
::2-4 SENTENCES
|
||||
|
||||
#### Have these security mechanisms been communicated to the development team and other stakeholders?
|
||||
|
||||
::Yes, everyone understands. Feedback is welcome.
|
||||
|
||||
::No, this is a risk that is noted in the [Risk
|
||||
Management](plan#risks) section.
|
||||
|
||||
<!-- End Markdown content -->
|
||||
</xmp>
|
||||
|
||||
<div w3-include-html="_words-of-wisdom.html"></div>
|
||||
<div w3-include-html="_footer.html"></div>
|
||||
|
||||
<script>
|
||||
w3IncludeHTML();
|
||||
</script>
|
||||
|
||||
<script src="http://strapdownjs.com/v/0.2/strapdown.js"></script>
|
||||
<!-- Include it AFTER strapdown -->
|
||||
<script src="assets/strapdown/strapdown-topbar.min.js"></script>
|
||||
<!-- Include it AFTER EVERYTHING -->
|
||||
<script src="assets/logo.js"></script>
|
||||
<script src="assets/themeswitcher.js"></script>
|
||||
|
||||
</body>
|
||||
</html>
|
Reference in New Issue
Block a user