To respond to the increasing number of federal cybersecurity recommendations and regulations, cybersecurity leaders and their teams need to be confident in the transparency and resiliency of their security processes. The key is a strong and well documented risk management program. This is imperative for the compliance or incident audits that come with regulations.
In this blog, we dive into the key insights from Sysdig’s Practical Cloud Security Guidance in the Era of Cybersecurity Regulation and highlight suggested priorities stemming from the leadership discussion points in the paper. This guidance will enhance the transparency of your risk management program and the resiliency of your security program through improved documentation and configuration.
Combat risk with speed and transparency
The timely identification of security events and gathering relevant signals are crucial for meeting regulatory cybersecurity disclosure requirements and compliance standards. Organizations must establish efficient processes to detect potential security incidents promptly and collect necessary evidence to support regulatory disclosures. In addition, documenting these detection processes ensures transparency and accountability in demonstrating compliance with regulatory guidelines that require both the timely detection and disclosure of cybersecurity incidents.
Furthermore, information sharing also plays a vital role in strengthening global cybersecurity efforts. It is essential for organizations to openly coordinate and collaborate with other entities, including government agencies, regional and industry-specific organizations, and cybersecurity researchers, to share vulnerability disclosures and threat intelligence. By fostering open communication and collaboration, organizations can collectively enhance their cybersecurity defenses and respond more effectively to emerging threats.
Finally, documenting processes for Coordinated Vulnerability Disclosure (CVD) is essential for transparency and effective risk management programs. Sharing relevant data and insights through CVD processes helps organizations assess and mitigate risks more efficiently, contributing to overall cybersecurity resilience and preparedness. This documentation should also define procedures for receiving, evaluating, and addressing vulnerability reports from external parties, such as security researchers or affected organizations. Establishing comprehensive CVD practices contributes to a more secure ecosystem by facilitating responsible vulnerability disclosure and remediation practices.
Codify your risk management
Code artifacts are defensible and can be used as supportive evidence during regulatory, risk, and audit reviews. By adopting practices such as infrastructure as code (IaC), policy as code (PaC), and detection as code (DaC), organizations can translate complex risk management policies and procedures into executable code that becomes enforceable rules for consistency, accuracy, and compliance across enterprise environments.
Infrastructure as Code
IaC is the practice of managing and provisioning computing infrastructure (virtual machines, networks, containers, etc.) through machine-readable definition files, rather than manual physical hardware configuration of each resource or the use of an interactive configuration tool. IaC can be automated using scripts and declarative definitions, and is therefore consistent and easily scalable for hundreds or thousands of resources.
Implementing IaC in an enterprise involves these steps:
- Choose an IaC tool for defining and managing infrastructure. Popular choices include Terraform, AWS CloudFormation, Azure Resource Manager, and Google Cloud Deployment Manager.
- Define infrastructure by writing code (declarative or imperative) to describe the desired state of your infrastructure. This can include servers, networking components, storage, security settings, etc.
- Store your infrastructure code in version control systems, like Git, to manage changes, track history, and collaborate with others.
- Automate deployment and management of your infrastructure based on code changes using Continuous Integration/Continuous Deployment (CI/CD) pipelines.
- Monitor and update your infrastructure code continuously so it reflects changes in requirements and best practices.
Policy as Code
PaC is the concept of codifying policies and governance rules for IT infrastructure and applications in the form of executable code, making it easier to audit. This approach also ensures that policies are consistently enforced across all environments and within the software development lifecycle (SDLC), and violations can be automatically detected and remediated.
Implementing PaC in an enterprise involves these steps:
- Identify and define policies for security, compliance, access control, and operational best practices.
- Write policies as code using policy definition languages or frameworks such as Open Policy Agent (OPA), AWS Config Rules, Azure Policy, or custom scripts.
- Integrate with CI/CD pipelines by incorporating policy checks to automatically evaluate infrastructure and application changes against defined policies.
- Implement continuous monitoring to detect policy violations in real time and automatically enforce remediation actions.
- Generate reports and logs to track policy compliance and audit trails for governance purposes.
Detection as Code
DaC refers to the practice of incorporating security monitoring and detection capabilities directly into the code and infrastructure deployment processes of the DevOps pipeline. This approach aims to automate the deployment of security controls and monitoring mechanisms alongside the development and deployment of software applications and infrastructure components, therefore shifting security practices earlier in the SDLC. This practice means you don’t have to compromise on either security or the speed of innovation.
Implementing DaC in an enterprise involves these steps:
- Choose monitoring and detection tools that support integration with code and automation. This could include tools like Falco, Prometheus, Grafana, AWS CloudWatch, Azure Monitor, ELK Stack (Elasticsearch, Logstash, Kibana), or custom scripts.
- Define monitoring requirements by identifying the security events, metrics, logs, and indicators that need to be monitored for detecting potential threats or anomalies across the enterprise. This could include system logs, application logs, network traffic, user activities, etc.
- Write detection rules and logic as code using the chosen monitoring tools or frameworks. This involves writing queries, rules, alerts, and thresholds in a declarative or script-based format.
- Integrate with CI/CD pipelines to automatically deploy monitoring configurations alongside application deployments. Use IaC principles to provision and configure monitoring resources.
- Automate deployment using an infrastructure automation tool to provision and configure the detection and monitoring infrastructure as part of the deployment process. This might include monitoring agents, logging pipelines, and dashboards.
- Implement continuous monitoring and real-time alerting based on predefined detection rules. Ensure that security events and anomalies are detected promptly and trigger automated responses or notifications.
- Monitor and tune detection rules continuously based on observed security events, feedback from incident response, and changing threat landscapes.
- Integrate with security orchestration platforms to automate incident response, investigation, and remediation workflows based on detected security events.
- Implement compliance checks and generate reports based on monitoring data to ensure adherence to security policies, regulations, and standards.
Fortify risk management with a secure supply chain
Exhaustive risk management involves comprehensive analysis of all code and dependencies to identify potential vulnerabilities and security issues. Implementing “as code” approaches, such as IaC or PaC, supports the goal of ensuring authenticity, integrity, and validity of code and dependencies throughout the development and deployment lifecycle.
To further enhance security and reduce risk, it’s advisable to use private registries and repositories for pulling secure components rather than relying solely on public sources. However in practice, the opposite is true according to the Sysdig 2024 Cloud-Native Security and Usage Report. The report notes that a majority of organizations are still using public repositories. Public repositories may pose increased risks due to reduced visibility and potential exposure to malicious or compromised components.
In addition, during supply chain procurement, it’s critical to involve finance and legal teams to ensure Bills of Materials (BOMs) are included from the vendor and agreed upon. This proactive approach addresses potential attack surfaces and supply chain risks through transparency, mitigating the risk of incorporating insecure or unauthorized components into the software or system.
Maintaining and documenting your own BOMs based on engineering-chosen standards ensures transparency and accountability in managing software components. These BOMs should accurately describe the composition of software or system elements and align with regulatory standards and disclosure requirements, contributing to a robust risk management program that prioritizes security and mitigates potential threats in software development and supply chain management.
Minimize attack surface with policy guardrails
Risk is introduced when a system deviates from hardened, secure baselines. This can happen due to manual changes, software updates, or other factors that gradually alter the state of the system. Misconfigurations and drift create opportunities for attackers to exploit vulnerabilities and gain unauthorized access. To mitigate these risks, implement policy guardrails, or restrictive parameters, to enforce secure configurations and ensure that systems adhere to predefined security baselines.
These guardrails serve as proactive measures to prevent configuration or drift and maintain the integrity and security of an environment. By implementing drift control mechanisms, organizations can continuously monitor and enforce compliance with secure configurations, reducing the likelihood of security incidents resulting from misconfigurations.
Conclusion
Delivering secure and compliant services while adhering to diverse regulatory requirements is becoming increasingly more difficult. A proactive and continuous improvement approach is necessary to meet compliance requirements and maintain resiliency. The best way to do so is through transparency in coordination, collaboration, and documentation.