5.2.A
Explain how the state or classification of data impacts the type and degree of security applied to that data. |
- 5.2.A.1 Organizations implement specific security controls to comply with legal requirements based on the types of data they collect, store, process, and transmit.
- 5.2.A.2 Data can be classified by their state.
- Data at rest are stored on a drive. It is important to protect the physical drive storing the data from destruction or theft. Data at rest can also be encrypted so that if an adversary steals it, they can’t immediately read the data.
- Data in transit are being sent from one device to another. If the data are being transferred over physical media (e.g., cables) it is important to protect the media. Data in transit can also be encrypted so that if an adversary intercepts it, they can’t immediately read the data.
- Data in use are being processed by software or a person. Access controls can be used to limit who or what has the ability to use data in different ways (e.g., view or edit). Data must be unencrypted to be used.
- 5.2.A.3 Organizations often categorize data according to their sensitivity and prioritize a higher degree of security for more sensitive information.
- 5.2.A.4 Laws and regulations can require certain types of data to be stored, transmitted, and handled according to specific rules.
- Personally identifiable information (PII) is any data that allows someone to be identified and includes (but is not limited to): name, signature, phone number, address, biometric data (e.g., fingerprints), social security number, date of birth, and email address. The protection of this data is covered by many laws but most notably The Privacy Act of 1974 and for children under the age of 13 the Children’s Online Privacy Protection Act of 1998.
- Protected health information (PHI) is any data related to an individual’s health, treatment, payment for healthcare at any time and includes (but is not limited to): test results, treatment records, hospital records, doctor visit notes, and health provider payment records. The protection of PHI is included in the Health Insurance Portability and Accountability Act of 1996.
- Payment card information (PCI) is the data collected by organizations to process payments via cards (e.g., credit cards) and includes the following: name, account number, expiration date, address, and CVV code. The protection of this data is regulated by the Payment Card Industry Data Security Standard (PCI-DSS).
- 5.2.A.5 Organizations that collect regulated data will label them and have policies that comply with the legal or regulatory requirements for the safe storage, transmission, and handling of these data.
|
5.2.B
Identify managerial controls related to application and data security. |
- 5.2.B.1 A cryptography policy will describe the acceptable encryption protocols and key parameters for an organization and may include:
- A list of encryption algorithms approved for specific uses
- Minimum or maximum key lengths
- Cryptographic key-generation requirements and parameters
- Cryptographic key-storage requirements
- 5.2.B.2 A web application security policy will outline the requirements and parameters for testing and mitigating web application vulnerabilities in an organization, and it may include:
- Parameters for when an application is subject to a security assessment
- Timelines for remediating vulnerabilities based on level of risk
- Parameters for how an application security assessment is to be carried out (e.g., using specific tools or according to specific frameworks)
|
5.2.C
Determine an appropriate access control model to protect applications and data. |
- 5.2.C.1 Access control enforces which users or applications (called subjects) can access, modify, add, or remove (called operations) which files or applications (called objects). Access control models describe how to determine which subjects have what type of access to which objects.
- 5.2.C.2 Role-based access control (RBAC) assigns every subject to a role and defines which roles have which types of access to which objects.
- Illustrative examples for 5.2.C.2:
- An example of a role at a company might be “accountant,” and one type of object could be the payroll software. Role-based access could be used to ensure that only subjects who are assigned to the role of “accountant” have access to the payroll software object.
- 5.2.C.3 Rule-based access control (RuBAC) checks a set of rules to determine what type of access a subject should have for a specific object and then allows or denies types of access based on the rules. This access control model is typically layered on top of another access control model.
- Illustrative examples for 5.2.C.3:
- There is a rule that prohibits subjects (even those who would normally have access) from accessing a certain database (the object) outside of local working hours. When a subject attempts to access the database, even if they are authorized to access it, they will be denied access if it is outside the time designated by the rule.
- 5.2.C.4 Discretionary access control (DAC) gives individual subjects the ability to set the type of access that other subjects have on objects they own. In DAC models some subjects are designated as administrators or super users, and they have the ability to override the access controls established by other subjects.
- Illustrative examples for 5.2.C.4:
- Bob creates a file (an object) and decides to give Alice permission to edit the file, to give Frank permission to view the file only, and to deny everyone else access to the file altogether.
- 5.2.C.5 Mandatory access control (MAC) follows strict rules for which types of access each subject level has for objects that are above their level, at their level, or below their level. Subject and object levels are assigned by an external administrator.
- 5.2.C.6 The Bell-LaPadula model is a MAC model that is often used by governments and military organizations to control the security of information. This model has the following two important properties:
- i. The Simple Security Property states that subjects may not read objects that are above their level.
- ii. The * (Star) Security Property states that subjects may not write to objects below their level.
- These rules taken together are often summarized as “write up, read down” (WURD).
- 5.2.C.7 The principle of least privilege is the idea that entities should be given exactly as much access as they need to perform their function and no more.
|
5.2.D
Configure access control settings on a Linux-based system. |
- 5.2.D.1 Authorization is when an entity is granted permission to have a certain type of access to a resource. Access controls are put in place to control which users have what types of access to which data.
- 5.2.D.2 There are three types of access to a file in Linux that can be set, and they always come in the following order:
- i. Read access allows a user to view the contents of a file.
- ii. Write access allows a user to make changes to a file.
- iii. Execute access allows a user to run a binary file such as a program.
- These are abbreviated rwx, respectively. If a user only has read and execute permissions (not write), then it would display as r-x. The - symbol indicates the absence of that permission.
- 5.2.D.3 There are three default entities for which permissions are set and always in this order: (1) the file owner, (2) the file group, and (3) all other users. The three sets are displayed with no spaces (e.g., rwxrwxrwx).
- 5.2.D.4 To view the current permission settings for a file, use the command ls -l, which will show the current settings for the default entities. If there is a + symbol at the end of the permissions, this means that other permissions have been set for that file and it can be viewed with the getfacl command.
- 5.2.D.5 To modify the permission settings for a file, use the chmod command. This command can be used with the numeric method or the symbolic method.
- 5.2.D.6 To use chmod in the numeric method the syntax is chmod ### filename. Each of the three ### represents one of the three entities mentioned above (the owner, the group, other nongroup users).
- The first # = the owner
- The second # = the group
- The third # = other nongroup users
- The permission for each entity is determined by adding up the values for the types of access to be granted:
- 0 = no permissions
- 1 = execute
- 2 = write
- 4 = read
- Therefore 3 sets permission to write and execute, 5 sets permission to read and execute, 6 sets permission to read and write, and 7 sets permission to read, write, and execute.
- Illustrative examples for 5.2.D.6:
- The command chmod 750 test would set the permissions for the owner to read, write, and execute, for the group to read and execute, and for everyone else to no access at all.
- The command chmod 543 test would set the permissions for the owner to read and execute, for the group to read only, and for everyone else to write and execute.
- The command chmod 777 test would set the permissions for all three entities to read, write, and execute for the file test.
- 5.2.D.7 To use chmod in the symbolic method the syntax is chmod entity +(or –) permission filename. The entities are the user owner, the group, and other nongroup users. Each entity is represented with a single letter.
- u = user owner
- g = group
- o = others
- a = all
- Permission can be either added or removed to any combination of entities.
-
- – = remove the permission
- The permissions that can be set are read, write, and execute.
- r = read
- w = write
- x = execute
- Entities and permissions can be combined in a single command. To add the read and execute permissions for the group and user owner for a file called testfile, the command would be chmod ug+rx testfile.
|
