This final assignment is the logical continuation of assignment #1.
In assignment #1, you researched your organization or school to determine its database architecture, and you designed an Assessment and Analysis plan (Phase 1 of the Security Architecture Cycle) for your organization. In particular, you had to:
- Identify the assets to be protected
- Define and prioritize the threats against those assets
In this final assignment, you are asked to (partially) implement Phase 2 of the Security Architecture Cycle ("Design and Modeling", described on page 25 of the textbook). Armed with the knowledge you acquired during this term, you should be able to write policies and to prototype a security architecture that fit the needs of the business (or school) you selected in assignment #1.
In particular, you should address:
- What security policies need to be put into place in order to mitigate the identified threats? Security Policies are addressed on page 27. Some additional guidelines and examples are given below.
- What firmware/software changes need to take place to minimize vulnerabilities and support policies?
Given the database management system used in your selected environment and given the policy requirements, what changes in software version/configuration must be done?
- What security tools or applications should be added to minimize risk?
You are asked to include the description of the environment, the identified assets and threats from assignment #1 in the final assignment. Please feel free to make some "guesses" about the described environment.
Your final submission should be professional-looking. The expected length is between 6 to15 pages.
Guidelines for writing the policy:
- A security policy describes what it means for an organization to be secure. It is an agreed upon document that executive management uses to communicate its security goals and objectives. Thus, the language should be appropriate for all employees.
- The goal of such a policy is generally to protect valuable and/or confidential information from unauthorized access, but also to limit legal liability and prevent waste or inappropriate use of organization resources. Phrases such as "must", "should", or "will" are used to establish baseline expectations for behavior by employees and to authorize audits and monitoring.
- A security policy typically includes:
o Scope (1 paragraph)
o Goals (1 paragraph)
o Information classification (1-2 paragraphs)
o Actual requirements: as an itemized list. Specifically, database policy statements could address:
- Roles and responsibilities: Roles at the organization level could include application developer, database user, database administrator, database owner, application owner etc. Responsibilities should be designated.
- Database access types
- Authentication and authorization - a password policy should be defined or referenced
- Use of encryption (files, data in transit, backup files), managing encryption keys
- Backups and recovery (weekend or weekdays, on-line or off-line, incremental or full, etc.)
- Audits (auditor, frequency of audits, what is audited)
- Use of multi level security
- Use virtual private databases
- Database servers hardening (firewall/intrusion detection system, secure configuration, patch management, vulnerability assessment)
- Change management (ensure privileged accounts are documented, administered, monitored, and reviewed)
o Reference to supporting documents (existing procedures and guidelines)
o Reference to regulatory compliance (if any)
o Consequences for non-compliance of the security policy (1 - 2 paragraphs)
The following are sample security policies that could help you develop your database security policy:
- server security policy
(https://www.sans.org/security-resources/policies/server-security/pdf/server-security-policy ) ,
- Mobile Employee Endpoint Responsibility Policy
(https://www.sans.org/security-resources/policies/retired/pdf/mobile-employee-endpoint-responsibility-policy )