Post Syndicated from Michael South original https://aws.amazon.com/blogs/security/scaling-a-governance-risk-and-compliance-program-for-the-cloud/
Governance, risk, and compliance (GRC) programs are sometimes looked upon as the bureaucracy getting in the way of exciting cybersecurity work. But a good GRC program establishes the foundation for meeting security and compliance objectives. It is the proactive approach to cybersecurity that, if done well, minimizes reactive incident response.
Of the three components of cybersecurity—people, processes, and technology—technology is the viewed as the “easy button” because in relative terms, it’s simpler than drafting a policy with the right balance of flexibility and specificity or managing countless organizational principles and human behavior. Still, as much as we promote technology and automation at AWS, we also understand that automating a bad process with the latest technology doesn’t make the process or outcome better. Cybersecurity must incorporate all three aspects with a programmatic approach that scales. To reach that goal, an effective GRC program is essential because it ensures a holistic view has been taken while tackling the daunting mission of cybersecurity.
Although governance, risk, and compliance are oftentimes viewed as separate functions, there is a symbiotic relationship between them. Governance establishes the strategy and guardrails for meeting specific requirements that align and support the business. Risk management connects specific controls to governance and assessed risks, and provides business leaders with the information they need to prioritize resources and make risk-informed decisions. Compliance is the adherence and monitoring of controls to specific governance requirements. It is also the “ante” to play the game in certain industries and, with continuous monitoring, closes the feedback loop regarding effective governance. Security architecture, engineering, and operations are built upon the GRC foundation.
Without a GRC program, people tend to solely focus on technology and stove-pipe processes. For example, say a security operations employee is faced with four events to research and mitigate. In the absence of a GRC program, the staffer would have no context about the business risk or compliance impact of the events, which could lead them to prioritize the least important issue.
The breadth and depth of a GRC program varies with each organization. Regardless of its simplicity or complexity, there are opportunities to transform or scale that program for the adoption of cloud services, emerging technologies, and other future innovations.
Below is a checklist of best practices to help you on your journey. The key takeaways of the checklist are: base governance on objectives and capabilities, include risk context in decision-making, and automate monitoring and response.
Identify compliance requirements
__ Identify required compliance frameworks (such as HIPAA or PCI) and contract/agreement obligations.
__ Identify restrictions/limitations to cloud or emerging technologies.
__ Identify required or chosen standards to implement (for example NIST, ISO, COBIT, CSA, CIS, etc.).
Conduct program assessment
__ Determine desired end-state capability and maturity, also known as target profile.
__ Document and prioritize gaps (people, process, and technologies) for resource allocation.
__ Draft and publish a cloud strategy that includes procurement, DevSecOps, management, and security.
__ Define and assign functions, roles, and responsibilities.
Update and publish policies, processes, procedures
__ Update policies based on objectives and desired capabilities that align to your business.
__ Update processes for modern organization and management techniques such as DevSecOps and Agile, specifying how to upgrade old technologies.
__ Update procedures to integrate cloud services and other emerging technologies.
__ Establish technical governance standards to be used to select controls and that monitor compliance.
Conduct a risk assessment*
__ Conduct or update an organizational risk assessment (e.g., market, financial, reputation, legal, etc.).
__ Conduct or update a risk assessment for each business line (such as mission, market, products/services, financial, etc.).
__ Conduct or update a risk assessment for each asset type.
* The use of pre-established threat models can simplify the risk assessment process, both initial and updates.
Draft risk plans
__ Implement plans to mitigate, avoid, transfer, or accept risk at each tier, business line, and asset (for example, a business continuity plan, a continuity of operations plan, a systems security plan).
__ Implement plans for specific risk areas (such as supply chain risk, insider threat).
__ Use NIST Risk Management Framework (RMF) or other process to authorize and track systems.
__ Implement continuous monitoring of controls and risk, employing automation to the greatest extent possible.
Incorporate risk information into decisions
__ Link system risk to business and organizational risk
__ Automate translation of continuous system risk monitoring and status to business and org risk
__ Incorporate “What’s the risk?” (financial, cyber, legal, reputation) into leadership decision-making
Monitor compliance with policy, standards, and security controls
__ Automate technical control monitoring and reporting (advanced maturity will lead to AI/ML).
__ Implement manual monitoring of non-technical controls (for example periodic review of visitor logs).
__ Link compliance monitoring with security information and event management (SIEM) and other tools.
__ Automate application security testing and vulnerability scans.
__ Conduct periodic self-assessments from sampling of controls, entire functional area, and pen-tests.
__ Be overly critical of assumptions, perspectives, and artifacts.
Respond to events and changes to risk
__ Integrate security operations with the compliance team for response management.
__ Establish standard operating procedures to respond to unintentional changes in controls.
__ Mitigate impact and reset affected control(s); automate as much as possible.
Communicate events and changes to risk
__ Establish a reporting tree and thresholds for each type of incident.
__ Include general counsel in reporting.
__ Ensure applicable regulatory authorities are notified when required.
__ Automate where appropriate.
Want more AWS Security news? Follow us on Twitter.