The OWASP Top 10 Proactive Controls are used in the development of web applications.
Ensure strict access control mechanisms to regulate user, program, or process access to sensitive resources based on predefined policies. For example, enforce role-based or attribute-based access control at multiple levels, including business logic and database layers, to prevent unauthorized access and privilege escalation; Align access control enforcement across all entry points, such as web applications, APIs, and backend services, ensuring consistency and eliminating bypass risks; Maintain a clear distinction between authentication (verifying identity) and authorization (verifying permissions); Continuously monitor, log, and audit access attempts to detect and mitigate potential security threats.
1.Design Access Control Thoroughly Up Front Plan and implement access control policies early in the design phase, addressing all potential access points, roles, and data sensitivities. 2.Force Every Access Request to Go Through an Access Control Check Ensure that all requests for sensitive data or operations pass through a centralized access control check to enforce policies consistently across the application. 3.Consolidate the Access Control Check Use a centralized access control service to reduce complexity and improve maintainability, ensuring that all checks are consistent and auditable. 4.Deny by Default Implement default-deny access control, where access to resources is denied unless explicitly granted by predefined policies. 5.Principle of Least Privilege / Just in Time (JIT), Just Enough Access (JEA) Enforce the principle of least privilege by granting users only the minimum level of access necessary to perform their tasks. Implement JIT and JEA to dynamically allocate and revoke permissions based on specific needs. 6.Do not Hard-code Roles Avoid hard-coding roles directly into the application. Use a dynamic role management system to assign roles and permissions to users based on their actual job functions. 7.ABAC Policy Enforcement Point Example Implement Attribute-Based Access Control (ABAC) by creating policies that use attributes (e.g., user roles, data sensitivity, resource context) to enforce access decisions dynamically. An example could be restricting access to sensitive data based on user attributes such as department or clearance level. By designing comprehensive access control models, centralizing checks, and applying the principle of least privilege, organizations can ensure secure, granular access to resources across all environments.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-12-01-01-01 | Development access control thoroughly up front | Plan and implement access control policies early in the Development phase, considering all potential access points, roles, and data sensitivities. Address different access levels such as business logic and database row level. | Preparation | Security Teams, Software Architects |
| SSS-02-12-01-01-02 | Force every access request to go through an access control check | Ensure that every access request for sensitive data or operations goes through a centralized access control check to enforce policies consistently across the application. | Development | Security Engineers, Software Developers |
| SSS-02-12-01-01-03 | Consolidate the access control check | Use a centralized access control service to reduce complexity, improve maintainability, and ensure consistency in access checks across the application. | Development | Security Engineers, DevOps Teams |
| SSS-02-12-01-01-04 | Deny by default | Implement default-deny access control, where access to resources is denied unless explicitly granted by predefined policies. This ensures strict control over who can access what. | Development | Security Engineers, IT Operations |
| SSS-02-12-01-01-05 | Enforce principle of least privilege / just in time (jit), just enough access (jea) | Grant users only the minimum necessary access to perform their tasks by enforcing the principle of least privilege. Use JIT and JEA to dynamically allocate and revoke permissions based on needs. | Deployment | Security Teams, Compliance Officers |
| SSS-02-12-01-01-06 | Avoid hard-coding roles | Avoid embedding roles directly into the application code. Instead, use a dynamic role management system that assigns roles and permissions based on actual job functions and needs. | Development | Security Engineers, Software Architects |
| SSS-02-12-01-01-07 | Implement abac policy enforcement | Implement Attribute-Based Access Control (ABAC) by creating policies that use user attributes (e.g., department, clearance level) and resource context to make access decisions dynamically. | Development | Security Teams, Software Engineers |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1849) OWASP Proactive Controls OWASP Proactive Controls |
Ensure the protection of sensitive data such as passwords, financial records, personal information, and business secrets using strong cryptographic techniques. For example, encrypt data both at rest and in transit using industry-standard algorithms to prevent unauthorized access; Secure communications by enforcing TLS encryption, mitigating risks such as eavesdropping on public networks; Apply cryptographic hashing for passwords using secure methods like bcrypt, Argon2, or PBKDF2 to prevent credential theft; Adhere to compliance regulations such as GDPR and PCI DSS, ensuring legal obligations for data protection are met; Continuously monitor encryption implementations, audit cryptographic policies, and update outdated algorithms to maintain data confidentiality and security.
1. Protect Data at Rest 1.1 Store Passwords Safely Use strong hashing algorithms such as bcrypt, Argon2, or PBKDF2 with salting to securely store passwords. Never store passwords in plaintext. 1.2 Special Case: Application Secrets Management Use secure storage solutions (e.g., Vault, AWS KMS) to manage sensitive application secrets. Ensure secrets are encrypted at rest and access is restricted to authorized services only. 1.3 Key Life Cycle Implement key management practices that include secure key generation, storage, rotation, and destruction. Follow best practices such as NIST guidelines to manage keys throughout their life cycle. 2. Protect Data in Transit 2.1 Use Current Cryptographic Protocols Ensure TLS 1.2+ is used for all communications to protect data in transit. Avoid deprecated protocols like SSL and TLS 1.0/1.1. 2.2 Instruct Clients to Enforce Transport Level Encryption Require clients to use Transport Layer Encryption (TLS) for all connections and ensure it is enabled by default. Use HTTP Strict Transport Security (HSTS) to enforce encryption on supported clients. 2.3 Support Cryptographic Agility Implement cryptographic agility, meaning the ability to adapt to future cryptographic protocols or algorithms. Regularly assess and upgrade encryption methods to stay current with evolving security standards. By securing data at rest with strong hashing and encryption, and ensuring data in transit is protected using up-to-date cryptographic protocols, organizations can maintain robust security across their data environments.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-12-02-01-01 | Protect data at rest | Ensure that sensitive data is encrypted while stored (e.g., in databases or file systems), protecting it from unauthorized access in case of a data breach. | Development | Security Teams, Database Administrators |
| SSS-02-12-02-01-02 | Store passwords safely | Use strong cryptographic hashing algorithms such as bcrypt, Argon2, or PBKDF2 with salting to securely store user passwords. Never store passwords in plaintext. | Development | Security Engineers, Software Developers |
| SSS-02-12-02-01-03 | Manage application secrets securely | Use secure storage solutions, like Vault or AWS KMS, to manage sensitive application secrets. Ensure secrets are encrypted at rest and that access is restricted to authorized services only. | Development | DevOps Teams, Security Teams |
| SSS-02-12-02-01-04 | Implement key lifecycle management | Enforce secure key management practices, including key generation, storage, rotation, and destruction, in accordance with best practices like NIST guidelines. | Development | Security Engineers, IT Operations |
| SSS-02-12-02-01-05 | Protect data in transit | Ensure data is transmitted securely using modern cryptographic protocols (e.g., TLS 1.2 or higher), and instruct clients to enforce transport-level encryption (e.g., via HTTP Strict Transport Security - HSTS). | Deployment | Security Teams, Network Engineers |
| SSS-02-12-02-01-06 | Support cryptographic agility | Implement the capability to adapt to future cryptographic protocols or algorithms by regularly assessing and upgrading encryption methods to stay current with evolving security standards. | Post-deployment | Security Teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1849) OWASP Proactive Controls OWASP Proactive Controls |
Ensure all user input is properly validated and sanitized to prevent injection attacks and other security vulnerabilities. For example, implement strict input validation using allowlists and enforce proper data formatting to prevent SQL injection and remote code execution; Apply encoding techniques to escape special characters in user-supplied data before rendering it in web applications, mitigating cross-site scripting (XSS) risks; Handle exceptions securely by logging errors without exposing sensitive information, preventing attackers from gathering insights into system behavior; Continuously monitor and test input validation mechanisms to detect and remediate potential weaknesses, ensuring robust protection against injection-based exploits.
1. Prevent Malicious Data from Entering the System 1.1 Allowlisting vs Denylisting Allowlist inputs to accept only expected values, rather than denylisting which tries to block unwanted input. This reduces the chances of bypassing validation. 1.2 Client-Side and Server-Side Validation Perform input validation on both client and server sides. Server-side validation is mandatory for security, while client-side validation improves user experience. 1.3 Regular Expressions Use regular expressions (regex) cautiously. Ensure they are specific and well-constructed to prevent ReDoS attacks (regular expression denial of service). 1.4 Unexpected User Input (Mass Assignment) Prevent mass assignment by avoiding direct binding of user input to internal objects. Only allow expected and validated fields to be updated. 2. Limits of Input Validation Input validation is not a complete defense. It should be paired with output encoding and proper security controls to fully secure the application from injection and data manipulation attacks. 3. Use Mechanisms that Uphold the Separation of Data and Commands 3.1 JavaScript Injection Attacks Prevent JavaScript injection attacks by sanitizing and validating all dynamic content, and using Content Security Policy (CSP) to restrict executable code. 3.2 Validating and Sanitizing HTML Sanitize HTML inputs to ensure only safe content is rendered. Use trusted libraries to filter out unsafe HTML elements or attributes that could be exploited for XSS attacks. By allowlisting inputs, validating thoroughly, and maintaining the separation between data and executable commands, organizations can reduce risks of injection and unauthorized data manipulation.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-12-03-01-01 | Prevent malicious data from entering the system | Implement input validation to ensure only properly formatted data is accepted. Use allowlisting for inputs to only accept expected values, reducing the risk of malicious data entry. | Development | Security Engineers, Software Developers |
| SSS-02-12-03-01-02 | Validate inputs on both client-side and server-side | Perform input validation on both client-side and server-side to ensure consistency and security. While client-side validation improves user experience, server-side validation is mandatory for security. | Development | Frontend Developers, Backend Developers |
| SSS-02-12-03-01-03 | Use well-constructed regular expressions | Use regular expressions (regex) carefully, ensuring they are specific and optimized to avoid performance issues such as ReDoS (Regular Expression Denial of Service). | Development | Security Engineers, Software Developers |
| SSS-02-12-03-01-04 | Prevent mass assignment vulnerabilities | Avoid mass assignment vulnerabilities by ensuring that only expected and validated fields can be updated. Do not bind unfiltered user input directly to internal objects. | Development | Backend Developers, Security Teams |
| SSS-02-12-03-01-05 | Use mechanisms that uphold the separation of data and commands | Prevent injection attacks, including JavaScript injections and SQL injection, by keeping data and commands separate. Sanitize inputs, implement Content Security Policies (CSP), and use trusted libraries for sanitization. | Development | Security Engineers, Web Developers |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1849) OWASP Proactive Controls OWASP Proactive Controls |
Ensure security is embedded in application design from the beginning to prevent vulnerabilities and reduce future remediation costs. For example, follow secure design principles such as keeping architectures simple (KISS) to make security easier to implement and audit; Enforce secure defaults, ensuring applications are protected out-of-the-box without requiring user intervention; Avoid security by obscurity, ensuring transparency without relying on hidden mechanisms for protection; Minimize the attack surface by reducing exposed components and eliminating unnecessary functionalities; Apply Defense-in-Depth, layering security controls to contain potential breaches and limit their impact; Continuously assess and refine security architecture to proactively address emerging threats.
1. Design for Clarity and Transparency -Ensure clear security policies and explicitly define system behavior to avoid ambiguity. 2. Make it Easy to Do the Right Thing -Set secure defaults so users and developers follow best practices effortlessly. 3. Define and Enforce Trust Relationships -Clearly specify who/what is trusted and enforce strict access controls. 4. Minimize the Attack Surface -Reduce exposed components, unnecessary services, and open endpoints. 5. Use Well-Known Architecture Patterns -Follow proven security frameworks (e.g., Zero Trust, Defense-in-Depth) for consistent protection. By prioritizing clarity, secure defaults, and attack surface reduction, organizations strengthen security while simplifying compliance and enforcement.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-12-04-01-01 | Development for clarity and transparency | Ensure security policies are clear, and system behavior is explicitly defined to avoid ambiguity. This helps developers and users understand the security measures in place. | Development | Software Architects, Security Teams |
| SSS-02-12-04-01-02 | Make it easy to do the right thing | Set secure defaults to ensure users and developers follow best practices effortlessly. Any action that could compromise security should require an explicit, conscious choice. | Development | Software Architects, Product Managers |
| SSS-02-12-04-01-03 | Define and enforce trust relationships | Clearly specify who and what is trusted in the system and enforce strict access controls to minimize the risk of unauthorized access. | Development | Security Engineers, DevOps Teams |
| SSS-02-12-04-01-04 | Minimize the attack surface | Reduce the exposed components, unnecessary services, and open endpoints that attackers can target, thus minimizing the areas where vulnerabilities can be exploited. | Development | Security Engineers, IT Operations |
| SSS-02-12-04-01-05 | Use well-known architecture patterns | Follow proven security frameworks such as Zero Trust and Defense-in-Depth to ensure that multiple layers of protection are in place and reduce the risk of a single point of failure. | Development | Software Architects, Security Teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1849) OWASP Proactive Controls OWASP Proactive Controls |
Ensure applications and systems are configured securely by default to minimize the risk of exploitation without requiring manual adjustments. For example, enforce **hardened default settings**, such as strong authentication, encrypted communications, and least privilege access, reducing the likelihood of misconfigurations; Design software to **require explicit actions** to weaken security rather than relying on users to enable protections manually; Reduce developer and administrator burden by **providing pre-configured security measures**, ensuring products remain protected over time; Continuously review and update default security settings to adapt to evolving threats and maintain resilience against attacks.
1. Enforce Secure Default Configurations -Apply least privilege principles in infrastructure-as-code (IaC) configurations. -Disable unused accounts, software, and demo features to reduce attack surfaces. 2. Automate Configuration Audits -Use configuration scanning tools to detect security misconfigurations. -Implement CI/CD security checks to enforce secure settings before deployment. By ensuring secure defaults and automating verification, organizations reduce misconfiguration risks and strengthen system security.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-12-05-01-01 | Ensure secure defaults in configuration | Ensure that software starts in a secure state by default, with configurations that follow the principle of least privilege. Disable unnecessary accounts, services, and features that are not required. | Development | Security Engineers, DevOps Teams |
| SSS-02-12-05-01-02 | Continuous configuration verification | Continuously verify that configurations remain secure by default throughout the development lifecycle. Automate security checks to prevent misconfigurations. | Development | Security Engineers, QA Teams |
| SSS-02-12-05-01-03 | Disable unnecessary features and services | Disable unused capabilities, such as demo accounts, software, and non-essential features, to minimize the attack surface. | Development | Software Developers, IT Operations |
| SSS-02-12-05-01-04 | Adopt the principle of least privilege | Ensure that each component and user has the minimum level of access necessary to perform its functions, reducing potential risks from excess permissions. | Development | Security Engineers, System Administrators |
| SSS-02-12-05-01-05 | Review and update default security settings regularly | Periodically review and update default security settings to align with emerging threats and security best practices. Keep security configurations up to date. | Post-deployment | Security Teams, Compliance Officers |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1849) OWASP Proactive Controls OWASP Proactive Controls |
Ensure all libraries and frameworks used in development are secure and well-maintained to minimize security risks. For example, prioritize built-in security features of existing frameworks rather than introducing additional third-party libraries that require extra maintenance; Use only trusted and actively maintained libraries, verifying their sources and security track records before integration; Implement automated dependency monitoring and updates to patch vulnerabilities promptly, reducing exposure to supply chain attacks; Regularly audit and assess third-party components to ensure ongoing security compliance and resilience against evolving threats.
1. Best Practices to Identify Trusted Libraries -Use official sources (e.g., npm, PyPI, Maven) and prefer digitally signed packages. -Check for active maintenance, frequent updates, and a strong security track record. -Verify security advisories and CVEs via sources like OWASP Dependency Check or CycloneDX. 2. Best Practices to Keep Libraries Secure -Regularly update dependencies and remove unused or deprecated ones. -Use software composition analysis (SCA) tools to detect vulnerabilities. -Lock dependency versions using package managers to prevent unintended updates. -Prefer least privilege access when integrating libraries to limit security risks. By identifying trusted libraries and maintaining them securely, organizations can minimize risks from supply chain attacks and outdated dependencies.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-12-06-01-01 | Identify trusted libraries and frameworks | Use official sources (e.g., npm, PyPI, Maven) to select trusted libraries and prefer digitally signed packages. Ensure that the library or framework has a strong security track record, is actively maintained, and receives frequent updates. | Development | Security Teams, Software Developers |
| SSS-02-12-06-01-02 | Check for active maintenance and security advisories | Regularly check security advisories and CVEs (Common Vulnerabilities and Exposures) via sources like OWASP Dependency Check or CycloneDX. Only use libraries with an active and reliable security patch history. | Development | Security Engineers, Software Developers |
| SSS-02-12-06-01-03 | Regularly update dependencies | Keep dependencies up to date by regularly updating third-party libraries and removing any unused or deprecated ones. This reduces the risk of vulnerabilities due to outdated components. | Post-deployment | DevOps Teams, Security Engineers |
| SSS-02-12-06-01-04 | Use software composition analysis (sca) tools | Implement Software Composition Analysis (SCA) tools to automatically detect vulnerabilities within third-party libraries and dependencies. These tools help ensure that the libraries used are secure and up to date. | Development | Security Teams, QA Teams |
| SSS-02-12-06-01-05 | Limit access and use least privilege | When integrating third-party libraries, grant them only the minimum level of access necessary for their functionality. This limits potential security risks and prevents unnecessary exposure. | Development | Security Engineers, Software Developers |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1849) OWASP Proactive Controls OWASP Proactive Controls |
Ensure robust digital identity management by implementing secure authentication, session management, and identity verification mechanisms. For example, enforce strong authentication methods such as multi-factor authentication (MFA) to verify users reliably; Secure session management by preventing session fixation, enforcing timeouts, and protecting session tokens from theft; Assign experienced security engineers to oversee identity-related components due to their complexity and high security impact; Follow industry standards like NIST 800-63B to ensure best practices in authentication and identity lifecycle management; Continuously monitor and audit authentication and session controls to prevent identity-based attacks and unauthorized access.
1. Password Security -Enforce NIST 800-63b password guidelines and block weak passwords. -Use temporary, one-time links for password resets; avoid security questions. -Hash passwords using Argon2, bcrypt, or PBKDF2—never store in plaintext. 2. Server-Side Session Management -Generate high-entropy session IDs and expire sessions after logout, inactivity, or timeout. -Store sessions server-side, not on the client. 3. Client-Side Session Management (JWTs) -Use short-lived JWTs and store them in HTTPOnly cookies, not local storage. Implement token revocation for long-lived JWTs. 4. Secure Cookies -Set HttpOnly, Secure, and SameSite attributes to protect against XSS and CSRF. -Expire session cookies on logout and enforce HTTPS. By enforcing strong passwords, secure session handling, and protecting cookies, organizations can mitigate brute force, session hijacking, and credential theft.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-12-07-01-01 | Implement secure password requirements | Enforce strong password policies (e.g., minimum length, complexity) to ensure that passwords are difficult to guess or brute-force. Require users to choose secure passwords during account creation. | Development | Security Engineers, Software Developers |
| SSS-02-12-07-01-02 | Implement secure password recovery mechanism | Provide a secure method for users to recover or reset their passwords, such as multi-factor authentication (MFA) during the recovery process, to prevent unauthorized password changes. | Development | Security Teams, Product Managers |
| SSS-02-12-07-01-03 | Ensure secure password storage | Store passwords securely by using modern hashing algorithms like bcrypt, Argon2, or PBKDF2 with salting, and ensure that passwords are never stored in plaintext. | Development | Security Engineers, DevOps Teams |
| SSS-02-12-07-01-04 | Implement server-side session management | Ensure secure session generation, expiration, and invalidation on the server side. Implement measures such as session timeouts and token revocation to manage session integrity and prevent unauthorized access. | Deployment | Security Engineers, DevOps Teams |
| SSS-02-12-07-01-05 | Use client-side session management with jwt | Use secure client-side session management, such as JWT (JSON Web Tokens), for maintaining authenticated user sessions. Ensure that tokens are encrypted, have an expiration date, and are securely stored in browser cookies. | Development | Security Engineers, Web Developers |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1849) OWASP Proactive Controls OWASP Proactive Controls |
Ensure web applications utilize built-in browser security features to protect users from threats like cross-site scripting (XSS), clickjacking, and data leaks. For example, enforce security headers such as Content Security Policy (CSP) to prevent unauthorized script execution and X-Frame-Options to mitigate clickjacking attacks; Configure secure cookies with HttpOnly, Secure, and SameSite attributes to enhance session protection; Extend security measures beyond traditional browsers by applying appropriate HTTP headers for mobile apps, API clients, and smart devices; Continuously assess and update browser security configurations to defend against evolving client-side threats.
Implement security measures to harden browser behavior and mitigate risks such as information disclosure, XSS, clickjacking, and CSRF attacks. 1.Configure the Browser to Prevent Information Disclosure -Enforce security headers such as X-Content-Type-Options: nosniff and -Referrer-Policy to limit exposure of sensitive data. -Implement CSP (Content Security Policy) to control script execution and prevent data leaks. 2.Reduce the Potential Impact of XSS -Use CSP headers (Content-Security-Policy) to restrict script execution and block unauthorized inline scripts. -Sanitize and validate all user input before rendering it in the browser. -Implement HTTPOnly and Secure flags on cookies to prevent JavaScript-based session hijacking. 3.Prevent Clickjacking -Use the X-Frame-Options header (DENY or SAMEORIGIN) to block unauthorized iframe embedding. -Implement frame-busting scripts as a secondary protection mechanism. 4.Control the Browser’s Advanced Capabilities -Restrict clipboard access, geolocation, microphone, and camera permissions using the Feature-Policy header. -Enforce sandboxing for iframes to limit their execution capabilities. 5.Prevent CSRF Attacks -Use CSRF tokens for all state-changing requests (e.g., form submissions, API requests). -Enforce SameSite cookie attributes (Strict or Lax) to prevent unauthorized cross-origin requests. -Implement CORS policies that restrict cross-origin requests to trusted domains. By configuring browser security settings, enforcing security headers, and validating input, organizations can reduce attack surfaces and enhance web application security against client-side threats.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-12-08-01-01 | Configure the browser to prevent information disclosure | Set appropriate HTTP headers (e.g., X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security) to prevent sensitive information leakage through the browser, such as through content sniffing or insecure protocols. | Development | Security Engineers, Web Developers |
| SSS-02-12-08-01-02 | Reduce the potential impact of xss | Implement Content Security Policy (CSP) and sanitize user input to mitigate the risk of cross-site scripting (XSS) attacks. Limit the sources from which scripts can be executed. | Development | Security Teams, Web Developers |
| SSS-02-12-08-01-03 | Prevent clickjacking | Use the X-Frame-Options header or Content Security Policy (CSP) to prevent your website from being embedded in iframes, thereby blocking clickjacking attacks. | Development | Security Engineers, Web Developers |
| SSS-02-12-08-01-04 | Control the browser’s advanced capabilities | Use HTTP headers such as Feature-Policy (now part of Permissions-Policy) to control which browser features (e.g., geolocation, camera, microphone) are available to your web app, thereby reducing the potential attack surface. | Development | Security Engineers, Web Developers |
| SSS-02-12-08-01-05 | Prevent cross-site request forgery (csrf) attacks | Implement anti-CSRF tokens to protect your web application from CSRF attacks, ensuring that state-changing requests are made intentionally by authorized users. | Development | Security Engineers, Backend Developers |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1849) OWASP Proactive Controls OWASP Proactive Controls |
Ensure security events are logged and actively monitored to detect and respond to potential threats in real-time. For example, implement detailed security logs for authentication attempts, access control violations, and unusual activities to track potential security incidents; Utilize automated monitoring and alerting systems to identify anomalies and unauthorized access attempts; Store logs securely, ensuring they are tamper-resistant and retained for forensic analysis; Leverage the same logging frameworks used for debugging to integrate security monitoring seamlessly into development and operations workflows; Continuously review and refine logging policies to enhance threat detection and response capabilities.
Ensure consistent and secure logging practices across all systems to facilitate monitoring, auditing, and incident response. -Standardize logging formats and frameworks across the organization for consistency. Use tools like Apache Logging Services to unify logging across different programming languages (Java, PHP, .NET, C++). -Balance logging granularity by capturing critical details, such as timestamps, source IPs, and user IDs, while avoiding the logging of sensitive data like usernames or confidential business information unless properly protected. -Ensure time synchronization across all systems and nodes to maintain consistency in timestamps, improving log correlation and forensic analysis. By standardizing logging, capturing essential details securely, and ensuring timestamp accuracy, organizations can enhance security visibility, detect threats efficiently, and improve compliance with logging best practices.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-12-09-01-01 | Use a common logging framework | Standardize logging practices across the organization by using a common logging framework, such as Apache Logging Services, to ensure consistency in logs between different systems and technologies (e.g., Java, PHP, .NET, C++). | Development | Security Engineers, Software Developers |
| SSS-02-12-09-01-02 | Log sufficient, but not excessive data | Ensure logs contain essential information such as timestamps, source IPs, and user IDs to help identify potential security incidents. Avoid logging sensitive data like usernames or business-critical information unless extra security measures (e.g., encryption) are in place. | Development | Security Teams, DevOps Teams |
| SSS-02-12-09-01-03 | Synchronize time across nodes | Ensure that all systems within the network are synchronized to a common time source to prevent issues with inconsistent timestamps across logs. This is critical for accurate incident detection and forensic analysis. | Deployment | IT Operations, Security Engineers |
| SSS-02-12-09-01-04 | Implement automated monitoring | Set up automated monitoring systems to analyze security logs in real time, using tools like SIEM (Security Information and Event Management) to detect and alert on potential security incidents. | Post-deployment | Security Teams, IT Operations |
| SSS-02-12-09-01-05 | Ensure secure storage and access to logs | Protect logs from unauthorized access or tampering by storing them securely. Use encryption and access control mechanisms to ensure that only authorized personnel can access or modify security logs. | Post-deployment | Security Engineers, Compliance Officers |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1849) OWASP Proactive Controls OWASP Proactive Controls |
Ensure servers are protected against SSRF attacks, which exploit vulnerable request handling to perform unintended actions on internal or external services. For example, enforce strict allowlists for outbound requests, blocking unauthorized access to internal networks and sensitive resources; Validate and sanitize user-supplied URLs to prevent manipulation of server-side requests; Implement network segmentation to limit the server’s ability to reach restricted services; Enforce least privilege access for server-to-server communications, ensuring that requests cannot be abused for privilege escalation; Continuously monitor and log outgoing requests to detect and respond to suspicious activity.
Implement multiple layers of defense to prevent Server-Side Request Forgery (SSRF) attacks. -Validate and sanitize input to ensure that only expected and safe URLs can be processed. -Use an allowlist for outbound requests, restricting access to only trusted domains and blocking unauthorized external or internal resources. -Secure XML parsers to prevent XML External Entity (XXE) attacks, disabling external entity resolution when parsing XML. -Account for Unicode encoding and character transformations when performing input validation to prevent attackers from bypassing filters with obfuscated payloads. By validating input, enforcing allowlists, securing XML parsers, and handling character encoding properly, organizations can effectively mitigate SSRF risks and prevent unauthorized server-side requests.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-12-10-01-01 | Implement input validation | Validate all user inputs to prevent unauthorized or malformed data from reaching the system. Ensure that input data is sanitized and validated against expected formats to prevent SSRF attacks. | Development | Security Engineers, Software Developers |
| SSS-02-12-10-01-02 | Use an allow-list for outgoing requests | If outgoing requests are necessary, ensure that the target domains and IP addresses are checked against a predefined allow-list. Only allow trusted services and hosts to be contacted. | Development | Security Engineers, DevOps Teams |
| SSS-02-12-10-01-03 | Secure xml parsers to prevent xee | If XML is used for processing data, configure the XML parser securely to prevent XML External Entity (XEE) attacks, which could be leveraged by SSRF attackers. Disable support for external entities and DTDs. | Development | Security Engineers, Backend Developers |
| SSS-02-12-10-01-04 | Be cautious with unicode and character transformations | Carefully handle Unicode and other character transformations during input validation. Attackers can exploit encoding vulnerabilities to bypass filtering mechanisms, so ensure proper encoding checks are implemented. | Development | Security Engineers, Software Developers |
| SSS-02-12-10-01-05 | Monitor and restrict internal services access | Restrict access to internal services and resources from external systems. Ensure that only authorized requests can reach internal APIs or services, and monitor any unusual access patterns. | Post-deployment | Security Engineers, IT Operations |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1849) OWASP Proactive Controls OWASP Proactive Controls |