Showing results for 
Show  only  | Search instead for 
Did you mean: 
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Newcomer III

How con divide classified information from unclassified in a DB?



i`m no db expert and in the cissp is the topic about DB security.


One point is to that you should not mix classified and unclassified information in one table. Ok, understand.

But how it works if I divide the information in different tables and there is a relationship between them. 


The user who have access to the table with the unclassified information could have access to the classified information over the relationship. 


How the DB blocks this access? 


Hope you can help and bring it closer to my understanding.


Best regards


5 Replies

Mostly you can classify with below type in data


-- Public
-- General
-- Confidential – GDPR
-- Confidential
-- Highly Confidential
-- Highly Confidential – GDPR

Information Type

-- Banking
-- Contact Info
-- Credentials
-- Credit Card
-- Date of Birth
-- Financial
-- Health
-- Name
-- National ID
-- SSN
-- Other


There is option to display only recommended values to particular users using with encryption/decryption methods.

Community Champion

Well, I will start, and hopefully others will jump in.


I would say the answer depends on the Database being used.  Each DB has/have their own way of applying security.


My thoughts only:  Once you have classified the data (I recommend about four levels) and understand who needs/should have access, you need to sit with the DB admins and ensure that the appropriate queries are developed for users. Test these to ensure that the appropriate access is provided and only that access.


When dealing with DBs, where possible I recommend encryption however some DBs do not allow encryption.


Some measures that you should implement when dealing with DB include (but not limited to):


  • Physical security: Regardless of location (on-prem or in a cloud data center, ensure the security and environment. 
  • Administrative and network access controls: Who has access, what are their permissions, has the data owner approved all access, etc. 
  • End user account/device security: Who is accessing the DB. Watch for anomalies Where are users accessing data, etc. ,  
  • Encryption: When possible - ALL data 
  • Database software security: Ensure that the database management software is current (apply all patches as soon as they are issued)
  •  Backup security:  Implement the same security controls/measures that are applied to the DB.  
  • Auditing: Record all logins to the database server and operating system, specifically all operations performed on sensitive data as well.  For DBs that contain confidential/sensitive data, audits should become standard practice with reports being provided to the Data Owner.   
Defender I

@OliLue We need to start by being sure all are using the same definitions.

In the context of general data management, all information is classified, in the sense that the information owners and users have (often unacknowledgedly) decided that some of the information is private or sensitive, and other information is public or non-sensitive. Let's call this definition DefP (for Public). @97kamaraj has provided a  list of information classifications that represent more specific categories of that may need to be used by a given enterprise.


However, those of us with extensive military or government experience tend to use a different definition of Classified (note the capitalization) when referring to information. In this context Classified means information determined to be sensitive and not releasable to the public because its release would threaten national security. We can refer to this definition as DefG (for Government). Using DefP, we even have a category of Unclassified (DefG), which refers to non-sensitive information that is potentially releasable to the public.


Note that the process of determining information to be Classified or Unclassified (DefG) is the result of a classification (DefP) decision. It becomes obvious that the government usage of the term Unclassified (DefG) is confusing when conflating DefG with DefP, because information has to be classified (DefP) in order to determine that it is Unclassified (DefG). For instance,  a lot of Unclassified (DefG) information has been classified (DefP) as sensitive and not generally releasable, even though release does not threaten national security. The release of such Sensitive But Unclassified (SBU) (DefG) information to the public would violate strictures in law or regulation pertaining to personal privacy, contractual obligations, proprietary business information, et cetera. 


Side note: Consider the difference between data and information. Realize that a database organizes data in order to provide information based on how selected data is correlated and presented. In general, a data element of location (e.g. address or latitude/longitude coordinates) is not by itself private or sensitive. Nor is the name of an individual, or a date and time. However, if you provide information that brings together the identity of

an important government offical with location at a specific day and time, that information could well be highly sensitive and need to be Classified in order to protect the official from assassination attempts.


Now, to your question about segregating data into separate tables based on data classification (DefP). Look at the protection options from @dcontesti. You need to think about the protection of the information using Diana's list. Further, go back to the basics by thinking in terms of protecting the C-I-A of the information and of the date. DefG is all about protecting Confidentiality, but DefP needs to focus as much or more also on protecting  data Integrity and Availability. 


One detail point to consider. You are likely to have database users with differing levels of access to information, so your internal access controls have to allow for that. There are advanced database systems that offer "row based security" to help manage such limitations. For instance, everyone in a company should be able to find the office address and work phone number of other employees, but only HR staff should be able to see performance review information, and only selected managers and financial staff should have access to pay information. 



D. Cragin Shelton, DSc
My Blog
My LinkeDin Profile
My Community Posts
Newcomer III

Hi Cragin,


thanks for your detailed feedback. Step by step I got a better understanding of this topic.


Best regards


Newcomer III

Thanks for you feedback.
It is very helpful