Page 153 - DCAP309_INFORMATION_SECURITY_AND_PRIVACY

Unit 10: Databases Security

8. Encryption – including both data at rest such as encrypting specific rows, and data in Notes
transit such as TLS between the database server and Web application. Data backups would
also be incorporated.
9. Information classification – labeling needs for public, internal, confidential, etc.
10. Physical security – building, data center, and server security.
11. Removal of property – servers, drives, tapes, and other property.

12. Security testing and audits – what, how, when, and who will perform testing along with
what tools will be used.
13. Separation of duties – the roles/responsibilities of users, DBAs, security auditors and
others involved with database management.
14. System maintenance – patching, system purging/cleanups and malware updates.
15. System monitoring and incident response – the who, why, when and how of real-time
monitoring and audit logging, as well as specific requirements for maintaining a formal
incident response plan.

16. User authorization – adding/removing users and conceding admin rights for whom,
why, when and for how long.
There are a number of significant points I would like to make connected to database-centric
security policies. Firstly, if management hasn’t affirmed their support (i.e. they’re going to
squeeze and impose the policies), you might additionally decline this exercise on the whole. So
get them on board first. Second, range your policies at the highest level probable so you can
maximize the number of departments and systems included. Maximize the number of rules you
can really be in fulfillment with. Alternatively, if you can support it, don’t produce all of the
above policies for your databases and have another set for wireless networks, storage systems
and so on. Similarly, appreciate your organization’s regulatory needs at least to the point where
one set of policies addresses PCI, GLBA, HIPAA, SOX, etc. This will be best served if you have
compliance or IT governance committee that oversees and executes security policies. You don’t
want your own set of policies to handle if you can assist it.

Lastly, confirm you document your policies in a method that’ll make comprehension and
administration as simple as possible. The following policy elements are necessary for keeping
policies simple and convenient long-term.
1. Introduction – a short overview of the topic such as encryption.
2. Purpose – briefly outlines the high-level goal(s) and approach of the policy.
3. Scope – States which employees, departments and database systems are covered.

4. Roles and responsibilities – outlines who’s concerned and what they’re expected to do to
support the policy.
5. Policy statement – your actual policy statement/statements. You should have one policy
statement per subject. Alternatively, create a separate template for each of the policies
listed above that you prefer to use.

6. Exceptions – underscores the people, departments, databases, etc. that are not covered by
the policy.
7. Procedures – detailed steps on how the policy is being executed and enforced in your
environment. You may want to reference this information and place it in a separate
document.

LOVELY PROFESSIONAL UNIVERSITY 147