5.2: Protecting Applications and Data: Managerial Controls and Access Controls
Essential Questions
- How does classifying data as PII, PHI, or PCI determine what security controls you must implement?
- Why do data at rest, in transit, and in use require different protection strategies?
- When should you choose role-based access control versus discretionary access control for your organization?
- How do cryptography policies and web application security policies work together to protect data?
- What do Linux file permissions like
rwxr-xr--actually mean, and how do you set them correctly?
Overview
Imagine walking into a busy hospital where patient medical records are scattered on every desk, financial information is stored in unlocked filing cabinets, and anyone can access the pharmacy inventory system. The chaos would be obvious—sensitive health information mixed with public schedules, no clear boundaries around who can see what, and critical systems wide open to anyone who wanders by. This nightmare scenario illustrates what happens when organizations fail to classify their data properly and implement appropriate access controls.
The reality is more subtle but equally dangerous. Organizations handle multiple types of sensitive information simultaneously: employee personal data, customer financial records, proprietary research, and regulatory compliance documents. Without systematic approaches to data classification and access control, even well-intentioned employees can accidentally expose sensitive information, and malicious actors can easily access data they shouldn't see.
This lesson explores how data classification drives security decisions, from determining encryption requirements to setting access permissions. You'll learn to distinguish between different types of regulated data like personally identifiable information (PII), protected health information (PHI), and payment card information (PCI), understand how managerial controls like cryptography policies provide organization-wide security guidance, and master practical access control models that determine who can access what information. Finally, you'll gain hands-on skills in configuring Linux file permissions that translate security policies into technical reality.
How the State or Classification of Data Impacts the Type and Degree of Security Applied (5.2.A)
Data classification serves as the foundation for all security decisions because it determines what legal obligations you must meet, what technical controls you must implement, and what risks you face if protection fails. Understanding how to classify data correctly means recognizing not just what type of information you're handling, but also what state it's in and how that state affects your security responsibilities.
Organizations implement specific security controls primarily to comply with legal requirements based on the types of data they handle. The moment you begin processing personally identifiable information (PII), protected health information (PHI), or payment card information (PCI), you trigger specific regulatory frameworks that mandate particular security measures with significant penalties for non-compliance.
Data classification begins with understanding three fundamental states that information can exist in, each requiring different protection approaches. Data at rest refers to information stored on drives, servers, or databases. Protection focuses on physical security of storage devices and encryption of stored information. If an adversary steals a hard drive containing encrypted data, they face the challenge of breaking encryption rather than simply reading files directly.
Data in transit describes information moving from one location to another, whether across networks or through email systems. Transit protection focuses on preventing interception through encryption protocols like TLS for network communications. Even if communication channels are compromised, the data remains unreadable.
Data in use represents information being actively processed by applications or reviewed by users. This state presents unique challenges because data must be unencrypted to be useful, creating windows of vulnerability. Access controls become critical—you must ensure only authorized individuals can view, modify, or process information during these vulnerable moments.
Legal frameworks provide specific classification categories that organizations must handle appropriately. Personally identifiable information (PII) includes any data allowing someone to be identified: names, social security numbers, addresses, biometric data. The Privacy Act of 1974 governs PII protection, while COPPA provides additional protections for children under 13.
Protected health information (PHI) encompasses any data related to an individual's health, treatment, or payment for healthcare services. This includes test results, treatment records, and doctor visit notes. HIPAA establishes comprehensive requirements for PHI protection affecting healthcare providers, insurance companies, and their business associates.
Payment card information (PCI) covers data collected to process card-based payments: names, account numbers, expiration dates, CVV codes. The Payment Card Industry Data Security Standard (PCI-DSS) mandates specific requirements for any organization processing, storing, or transmitting credit card information.
The practical impact of data classification appears in every security decision. When designing a database storing customer information, the presence of PII determines whether you need encryption, who can access administrative functions, how long you can retain data, and what you must do if a breach occurs.
Interactive Data Lifecycle Explorer
Explore how data security requirements change as information moves through different states: at rest, in transit, and in use. Each state presents unique threats and requires specific protections.
Key Insights:
- • Data security requirements change based on the state of the information
- • Each state has unique threats that require specific protection measures
- • Comprehensive security requires protecting data in all three states
- • Regulatory compliance often mandates specific protections for each state
- • The weakest state often determines overall data security
Identify Managerial Controls Related to Application and Data Security (5.2.B)
Managerial controls provide the organizational framework that translates security principles into consistent, enforceable practices across an organization. Unlike technical controls that directly prevent or detect attacks, managerial controls establish policies, procedures, and standards that guide how technical controls are selected, implemented, and maintained. Understanding these controls helps you recognize how organizational decisions about security policies directly impact the technical security measures you implement.
A cryptography policy serves as the foundational document that governs all encryption-related decisions throughout an organization. This policy addresses the critical challenge that cryptographic technology evolves rapidly, with new algorithms emerging, key length recommendations changing, and previously secure methods becoming vulnerable. Without centralized guidance, different departments might choose incompatible encryption methods, use weak algorithms, or implement cryptography incorrectly.
Effective cryptography policies specify approved encryption algorithms for different use cases, recognizing that file encryption, database encryption, and communication encryption may require different approaches. The policy establishes minimum and maximum key lengths that balance security requirements against performance constraints. Minimum key lengths ensure adequate security, while maximum key lengths prevent performance problems from unnecessarily long keys that don't provide additional security benefits.
Cryptographic key generation requirements address one of the most critical aspects of encryption security. The policy specifies how cryptographic keys must be created, ensuring they use proper random number generation, adequate entropy sources, and approved key derivation functions. Poor key generation can undermine even the strongest encryption algorithms, making this aspect of the policy particularly important for overall security.
Key storage requirements govern how encryption keys are protected throughout their lifecycle. The policy addresses physical security for key storage devices, access controls for key management systems, backup and recovery procedures for critical keys, and secure deletion procedures when keys are no longer needed. Since the security of encrypted data depends entirely on the security of the encryption keys, these storage requirements often represent the most detailed section of cryptography policies.
A cryptography policy builder named "5.2-crypto-policy-builder". Interactive features: (1) organization type selector (healthcare, finance, education, general business); (2) data sensitivity assessment; (3) policy template generator with appropriate algorithms and key lengths; (4) compliance checker for relevant regulations; (5) implementation timeline creator; (6) policy review and approval workflow simulator. Educational goal: demonstrate how organizational needs drive cryptography policy decisions.
Organizational Cryptography Policy Generator
Build a comprehensive cryptography policy based on your organization's specific requirements, threat model, and compliance needs. This tool recommends appropriate cryptographic standards and generates policy documentation.
Policy Requirements
Available Cryptographic Standards
AES-128
AES-256
RSA-2048
RSA-4096
ECC P-256
ECC P-384
SHA-256
SHA-3
DES
MD5
Policy Development Best Practices:
- • Regularly review and update cryptographic standards as technology evolves
- • Consider quantum-resistant algorithms for long-term data protection
- • Balance security requirements with performance and implementation costs
- • Ensure compliance with relevant industry and government standards
- • Document exceptions and risk acceptances with appropriate approvals
A web application security policy addresses the specific challenges that web-based applications face, including input validation, authentication mechanisms, session management, and vulnerability assessment procedures. This policy becomes increasingly important as organizations rely more heavily on web applications for critical business functions and customer interactions.
The policy establishes parameters for when applications require security assessments, typically based on factors like the sensitivity of data they handle, their exposure to external networks, and the potential impact of compromise. Applications handling PII, PHI, or PCI data usually require more frequent and comprehensive assessments than internal tools processing non-sensitive information.
Identify Managerial Controls Related to Application and Data Security (5.2.B)
Managerial controls provide the organizational framework that translates security principles into consistent, enforceable practices across an organization. Unlike technical controls that directly prevent or detect attacks, managerial controls establish policies, procedures, and standards that guide how technical controls are selected, implemented, and maintained.
A cryptography policy serves as the foundational document governing all encryption-related decisions throughout an organization. This policy addresses the critical challenge that cryptographic technology evolves rapidly, with new algorithms emerging and previously secure methods becoming vulnerable. Without centralized guidance, different departments might choose incompatible encryption methods or implement cryptography incorrectly.
Effective cryptography policies specify approved encryption algorithms for different use cases, recognizing that file encryption, database encryption, and communication encryption may require different approaches. The policy establishes minimum key lengths that ensure adequate security while preventing performance problems from unnecessarily long keys. Cryptographic key generation requirements address how keys must be created, ensuring they use proper random number generation and adequate entropy sources.
Key storage requirements govern how encryption keys are protected throughout their lifecycle, addressing physical security for key storage devices, access controls for key management systems, and secure deletion procedures when keys are no longer needed. Since the security of encrypted data depends entirely on the security of encryption keys, these storage requirements often represent the most critical aspect of cryptography policies.
Web application security policies address the specific challenges that arise when applications are accessible over networks and handle user input. These policies establish requirements for secure coding practices, input validation procedures, and vulnerability assessment processes. They specify how applications should handle authentication, session management, and error handling to prevent common vulnerabilities like SQL injection and cross-site scripting.
Development lifecycle requirements ensure that security considerations are integrated throughout the application development process rather than being added as an afterthought. This includes requirements for threat modeling during design phases, security testing during development, and security reviews before deployment.
Cryptography policies and web application security policies work together to create comprehensive security frameworks. A web application handling sensitive data must comply with both policies: using approved encryption algorithms while following secure development practices. This layered approach ensures that technical implementations align with organizational security standards.
Organizational Cryptography Policy Generator
Build a comprehensive cryptography policy based on your organization's specific requirements, threat model, and compliance needs. This tool recommends appropriate cryptographic standards and generates policy documentation.
Policy Requirements
Available Cryptographic Standards
AES-128
AES-256
RSA-2048
RSA-4096
ECC P-256
ECC P-384
SHA-256
SHA-3
DES
MD5
Policy Development Best Practices:
- • Regularly review and update cryptographic standards as technology evolves
- • Consider quantum-resistant algorithms for long-term data protection
- • Balance security requirements with performance and implementation costs
- • Ensure compliance with relevant industry and government standards
- • Document exceptions and risk acceptances with appropriate approvals
Determine an Appropriate Access Control Model to Protect Applications and Data (5.2.C)
Access control models provide systematic approaches to determining who can access what information under which circumstances. Each model offers different advantages and trade-offs, making the selection of an appropriate model a critical security decision that affects both security effectiveness and operational efficiency.
Access control fundamentally involves managing relationships between subjects (users or applications), objects (files or applications), and operations (actions like read, write, or execute). The complexity arises from the scale of these relationships in real organizations—hundreds of subjects interacting with thousands of objects through multiple operations creates millions of potential permission combinations that must be managed consistently.
Role-based access control (RBAC) addresses this complexity by organizing subjects into roles that reflect their job functions. Instead of managing individual permissions for each user, RBAC assigns users to roles and grants permissions to roles, dramatically reducing administrative overhead while improving security consistency.
Consider a hospital example: the "doctor" role receives permissions to access patient medical records, prescribe medications, and update treatment plans. The "nurse" role gets permissions to view patient records and administer medications but cannot prescribe treatments. When a new doctor joins, the administrator simply assigns them to the doctor role, automatically granting appropriate permissions without individual permission decisions.
Rule-based access control (RuBAC) adds conditional access based on contextual factors like time of day, location, device type, or network connection. RuBAC recognizes that access appropriateness depends not just on who is requesting access, but also on the circumstances of the request. A database administrator might access financial databases during business hours from corporate networks but be denied the same access at night or from external networks.
Discretionary access control (DAC) places access control decisions in the hands of data owners, allowing individuals to determine who can access resources they create or control. Bob creates a document and decides to share it with Alice for editing and Frank for viewing. This provides flexibility and aligns with natural ownership concepts, but can create security gaps when data owners make poor access decisions.
Mandatory access control (MAC) removes discretionary decisions from users and enforces access control through system-wide rules that cannot be overridden. MAC systems assign security levels to both subjects and objects, then enforce strict rules about access based on relative security levels.
The Bell-LaPadula model represents the most well-known MAC implementation, enforcing two fundamental properties: the simple security property prevents subjects from reading objects above their security level (no read up), and the star property prevents subjects from writing to objects below their security level (no write down). These rules create the "write up, read down" principle preventing information from flowing from high-security to low-security levels.
The principle of least privilege applies across all access control models, requiring that entities receive exactly as much access as needed to perform their functions and no more. This reduces the potential impact of compromised accounts and limits insider threat scope.
Interactive Access Control Testing Environment
Simulate access control decisions using role-based access control (RBAC) and attribute-based access control (ABAC) models. Test different scenarios and understand how access control rules interact to grant or deny access to resources.
Select User
Select Resource
Test Access
Learning Objectives:
- • Understand how multiple access control rules interact and are prioritized
- • Experience the difference between allow and deny rules in access control
- • See how user attributes (role, department, clearance) affect access decisions
- • Learn to analyze access patterns and identify potential security gaps
- • Practice designing access control policies for different organizational needs
Configure Access Control Settings on a Linux-based System (5.2.D)
Linux file permissions represent a practical implementation of discretionary access control that every system administrator and security professional must understand. These permissions translate abstract access control concepts into concrete technical settings that determine who can read, modify, or execute files and directories. Mastering Linux permissions gives you hands-on experience with access control principles while providing essential skills for securing Unix-like systems.
Authorization in the Linux context means granting specific types of access to particular users or groups for individual files and directories. Linux implements this through a permission system that considers three types of access—read, write, and execute—and applies these permissions to three categories of users: the file owner, members of the file's group, and all other users on the system.
The three access types have different meanings depending on whether they apply to files or directories. Read permission allows users to view file contents or list directory contents. Write permission enables users to modify file contents or create, delete, and rename files within directories. Execute permission allows users to run executable files or enter directories to access their contents.
These permissions appear in a specific order when displayed: read (r), write (w), execute (x). When a user lacks a particular permission, a dash (-) appears in that position. So a file with read and execute permissions but no write permission would display as r-x.
Linux applies these three permission types to three categories of users in a fixed order: the file owner, the file group, and all other users. This creates a nine-character permission string like rwxrw-r-- that specifies exactly what each category of user can do with the file. Reading from left to right: the first three characters (rwx) specify owner permissions, the middle three (rw-) specify group permissions, and the final three (r--) specify permissions for all other users.
A Linux permissions calculator named "5.2-linux-permissions-calc". Interactive features: (1) visual permission grid with checkboxes for owner/group/other and read/write/execute; (2) live conversion between symbolic (rwxrw-r--) and numeric (764) representations; (3) file vs. directory permission explanation; (4) common permission scenarios with security implications; (5) chmod command generator; (6) permission troubleshooting scenarios where users debug access problems. Educational goal: provide hands-on practice with Linux permission concepts and commands.
To view current permission settings, you use the ls -l command, which displays detailed file information including permissions, ownership, and modification dates. The output might look like this:
Configure Access Control Settings on a Linux-based System (5.2.D)
Linux file permissions represent a practical implementation of discretionary access control that translates abstract access control concepts into concrete technical settings. These permissions determine who can read, modify, or execute files and directories, providing essential skills for securing Unix-like systems.
Authorization in Linux means granting specific types of access to particular users or groups for individual files and directories. Linux implements this through a permission system considering three types of access—read, write, and execute—applied to three categories of users: the file owner, members of the file's group, and all other users.
The three access types have different meanings for files versus directories. Read permission allows users to view file contents or list directory contents. Write permission enables users to modify file contents or create, delete, and rename files within directories. Execute permission allows users to run executable files or enter directories to access their contents.
These permissions appear in a specific order: read (r), write (w), execute (x). When a user lacks a permission, a dash (-) appears in that position. Linux applies these to three user categories in fixed order: file owner, file group, and all other users, creating a nine-character permission string like rwxrw-r--.
To view current permissions, you use the ls -l command:
-rw-r--r-- 1 alice staff 1024 Jan 15 14:30 document.txt
drwxr-xr-x 2 alice staff 256 Jan 15 14:25 reports/
The first character indicates file type (- for regular files, d for directories). The next nine characters show the permission string, followed by ownership information, file size, and modification timestamp.
You modify permissions using the chmod command with either numeric or symbolic methods. The numeric method uses three-digit numbers where each digit represents permissions for owner, group, and others respectively. Each permission type has a numeric value: read (4), write (2), execute (1). You add these values to create the permission digit.
chmod 754 filename # Owner: read+write+execute (7), Group: read+execute (5), Others: read (4)
The symbolic method uses letters for user categories (u for owner, g for group, o for others) and permission types (r, w, x):
chmod u+x filename # Add execute permission for owner
chmod g-w filename # Remove write permission for group
chmod o=r filename # Set other permissions to read only
Understanding security implications of different permission combinations helps you make appropriate access control decisions. Common secure patterns include 644 for regular data files (owner read/write, others read-only), 755 for executable files and directories (owner full access, others read and execute), and 600 for sensitive files like private keys (owner read/write only, no access for others).
Directory permissions require special consideration because they control access to the directory and the ability to access files within it. Users need execute permission on a directory to access files inside it, even if they have appropriate permissions for individual files.
Real-World Application
Consider a healthcare organization implementing HIPAA compliance. They must classify all patient information as PHI, implement role-based access control so only medical staff can access patient records, establish cryptography policies requiring AES-256 encryption for stored data, and configure Linux file permissions ensuring that database files are readable only by authorized service accounts. Each component reinforces the others to create comprehensive data protection that meets both security and regulatory requirements.
Further Reading & Resources
- NIST Special Publication 800-53: Security Controls for Federal Information Systems
- Linux File Permissions Guide
- SANS Data Classification Best Practices
- OWASP Access Control Cheat Sheet
- Bell-LaPadula Model Overview