5 No Nos for GRC Programs
for the Cloud
Post date: August 13, 2019
Cloud Operations Series
Security/GRC Part 3
5 warnings and a few tips and checklists as you set out designing and implementing your governance, risk, and compliance (GRC) program for the cloud.
This is a 10-minute read and Part 3 of a 3-part series focused on security and public cloud services. If you are just getting started in cloud, we recommend Part 1 (https://www.blog.ankr.com/copy-of-conquering-cloud-costs-part-1) and Part 2 (https://www.blog.ankr.com/copy-of-security-shopping-for-publi ). For cost savings, better features, and higher flexibility, consider new technologies like Ankr when preparing to purchase.
#1 You or your management team don't know what GRC is - Know what it is, what exposures you have/will have, what penalties are etc.
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.
Specific to cloud you will quickly realize there is extensive exposure to your organization. Reading through this checklist is just a start.
#2 - You or your management team don't have a program or plan - Do identify a scalable application that enables your company to develop a holistic GRC enablement model.
Here is a five step process to help you - even startups - on your journey.
- Vendor selection
- Governance structure
- Data model/taxonomy
- Strategic roadmap
- Design and implementation
Many cloud providers will have GRC (and security) specific FAQs, templates, and other information for customers on their site.
Depending on your subscription, Ankr Cloud lets you choose where your data is located making it easier to meet your GRC requirements.
#3 - You or your management team don't have objectives - It's not just having a plan, it's getting the plan done that ultimately matters.
Below is a simple checklist of best practices to help you on your journey. The key takeaways of the checklist are provide *basic* categories for governance on objectives and capabilities as simple goals. This is by no means complete, rather a basis for a framework.
Governance, Risk, and Compliance related checklist categories
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
__ Conduct a program assessment based on industry processes such as the NIST Cyber Security Framework (CSF) or ISO/IEC TR 27103:2018 to understand the capability and maturity of your current profile.
__ Determine desired end-state capability and maturity, also known as target profile.
__ Document and prioritize gaps (people, process, and technologies) for resource allocation.
__ Build a Cloud Center of Excellence (CCoE) team.
__ 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.
Risk management-related checklist
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.
__ Use NIST Special Publication 800-53, ISO ISO/IEC 27002:2013, or other control set to select, implement, and assess controls based on risk.
__ 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.
#4 - You or your management team don't know your industry compliance regulations
Regulatory compliance is when a company obeys the laws, regulations, guidelines and specifications that pertain to its business. Here are a few practical examples from TechTarget:
Sarbanes-Oxley Act (SOX) of 2002:
SOX was enacted in response to the high-profile Enron and WorldCom financial scandals. It’s meant to protect shareholders and the general public from accounting errors and fraudulent practices in the enterprise. Among other provisions, the law sets rules on storing and retaining business records in IT systems.
Health Insurance Portability and Accountability Act of 1996 (HIPAA):
HIPAA Title II includes an administrative simplification section that mandates standardization of electronic health records systems and includes security mechanisms designed to protect data privacy and patient confidentiality.
Payment Card Industry Data Security Standard (PCI DSS):
PCI DSS is a set of policies and procedures created in 2004 by Visa, MasterCard, Discover, and American Express to ensure the security of credit, debit, and cash card transactions.
Federal Information Security Management Act (FISMA):
Signed into law in 2002, FISMA requires federal agencies to conduct annual reviews of information security programs in order to keep risks to data at or below specified acceptable levels.
#5 Don't know compliance regulations where your customers live
In a global economy, it is also necessary to be aware of the laws that are enforced not just pertaining to your industry but also in the countries where your customers live.
The General Data Protection Regulation 2016/679 (GDPR) was enacted in mid-2018 largely over a public concern over privacy. It is a regulation in EU law on data protection and privacy for all individual citizens of the European Union and the European Economic Area. It also addresses the transfer of personal data outside the EU and EEA areas.
What types of privacy data does the GDPR protect?
Basic identity information such as name, address and ID numbers
Web data such as location, IP address, cookie data and RFID tags
Health and genetic data
Racial or ethnic data
Which companies does the GDPR affect?
Any company that stores or processes personal information about EU citizens within EU states must comply with the GDPR, even if they do not have a business presence within the EU. Specific criteria for companies required to comply are:
A presence in an EU country.
No presence in the EU, but it processes personal data of European residents.
More than 250 employees.
Fewer than 250 employees but its data-processing impacts the rights and freedoms of data subjects, is not occasional, or includes certain types of sensitive personal data.
Part 1 (https://www.blog.ankr.com/copy-of-conquering-cloud-costs-part-1) covered the basic questions you should ask about SLAs, pricing, lock in, business continuity, and of course security. As we mentioned big cloud is at constant risk for various types of internal or external threats. Data loss due to malicious activity, natural disaster, and/or human error are also ongoing concerns.
Part 2 (https://www.blog.ankr.com/copy-of-security-shopping-for-publi) discussed how you and your cloud service provider carry shared responsibilities - re security and governance - and still stand to lose access (and potentially control) over your own data and worst case the data itself. Redundancy via backups, maintaining an assertive security posture ongoing, and active management of your operational processes around your cloud all help mitigate and minimize risk of data theft and/or loss.
This post urges you to consider, plan, and build a solid GRC plan for not only your organization, but also for your third party vendors that host your data. Reducing third-party risk depends on appropriate vendor selection. Vet all potential vendors to ensure they have share the same values as your organization when it comes to data privacy and risk management.
This was the longest post we have shared but in cloud computing you can never be too careful. We thank you for your interest!
We invite you to learn more: www.ankr.com
Try Now: app.ankr.com