15 Considerations for Your Next Cloud Native Security Audit
Prisma, from Palo Alto Networks, sponsored this post.
Security audits have become more complex and nuanced in a cloud native world, where organizations typically run applications on more than one cloud provider. In this post, we look at the top considerations if you’re an organization that is running applications on multicloud infrastructure; especially the importance of a security audit for these applications.
Let’s start with the top 15 considerations to assess your current compliance posture:
- Do we track changes to the system in real-time?
- Do we discover new resources as soon as they are added?
- Do we continuously monitor for threats and vulnerabilities?
- Do we have a list of compliance standards that can be applied to new resources?
- Which parts of our compliance process can we automate, and which need to be done manually?
- Do we have compliance for the usage of core DevOps tools like GitHub and Jenkins?
- Do we have compliance measures for the usage of container images?
- Do we audit the security practices of open source projects we use?
- Do we have a centralized view of our compliance posture across all cloud locations?
- Do we collect audit logs for all cloud services and cloud resources in use?
- Are we able to glean the signal from the noise in audit logs?
- Do we follow RBAC or more granular attribute-based access controls?
- How many users have admin or superuser access to our cloud assets?
- How do we handle conflicts in permission?
- Do we have a way for identities to request additional access they need to perform key tasks?
DNSStuff rightly simplifies the discussion around security by saying that, “the two fundamental aspects of security are authentication and authorization.” Authentication is about who a user is. Authorization involves what resources, assets, and data they have access to. While both are important, let’s discuss authorization in some detail here.
Role-Based Access Control (RBAC) Is Outdated
RBAC was introduced way back in 1992 and has evolved little since. It is a good way to reduce some manual configuration for each person and just give a group of people the same access levels. However, it is too rudimentary for today’s diverse cloud native stack. By giving out permissions liberally rather than restricting them, RBAC makes it difficult to practice the principle of least privilege. The superior alternative is ABAC.
Enter Attribute-Based Access Controls (ABAC)
According to TechTarget, ABAC controls access based on a combination of attributes — user attributes may include name, nationality, organization, ID, role, security clearance, and so on. Examples of resource attributes include owner, name, data creation date, and so on; while environmental attributes include access location, time of access and threat levels.
Two vital components of implementing ABAC are policies and metadata. The policies define who is controlled by the rules for access. These policies are based on attributes or metadata such as those listed above.
Policies can vary in scope. Some can be generic policies that apply to multiple cloud locations, and some can apply only to a specific cloud instance. Unlike roles, policies can overlap. They are more malleable and flexible, which makes them ideal for cloud native setups where the system, identities and permissions are always changing. Policies can be replicated across cloud environments, applications and datasets. In this way, they save time and improve the security posture.
For policies to function well, they rely on the quality of the underlying metadata. This requires accurate categorization of data and ongoing maintenance as the system changes. Some examples of metadata tags include public, confidential and top secret. There can also be tags specific to teams, applications and services. As the data lifecycle continues and data combines with other data, the metadata should remain intact and become even more fine-grained.
Initially, this process of tagging with metadata would involve a considerable amount of manual effort; but it should be automated as much as possible. Systems like Prisma Cloud, that can automatically discover and tag newly-ingested resources and data, can be a huge time saver and ensure better security.
Auditing an Expansive Multicloud Stack
The State of Cloud Native Security 2020 survey says that “94 percent of all organizations use more than one cloud platform. A majority — 60 percent — use between two and five.”
However, every cloud vendor is busy building out their own walled garden, with little consideration for interoperability with their competitors. In this contradictory environment, it is up to organizations to ensure their multicloud operations are adequately secured and audited. This would require looking beyond the plain vanilla tools provided by the cloud vendors themselves, to other vendor-agnostic tools that can scale the complexity of a multicloud setup.
More specifically, security policies will need to be applied uniformly across cloud vendor platforms. Node-host configurations should be similar in implementation despite the vendor-specific terminology. Just as network requests traverse multicloud networks, troubleshooting of issues should similarly span across the entire multicloud network. Monitoring should include all environments in order to be comprehensive and useful.
Logging and alerting play a key role in facilitating a cloud native security audit. It is critical to have API logging turned on for all cloud services by default. Security monitoring should alert you about a lapse in best practices as important as this.
Finally, for industries that operate in highly-regulated sectors, like finance and healthcare, cloud native audits involve additional considerations. Regulatory compliance controls for PCI, HIPAA and GDPR should be enforced across the cloud native application lifecycle. While the same principles apply, the enforcement of these principles will be more stringent in these sectors, with additional checks and balances for the handling of PII and ePHI data.
But to even come close to this level of maturity, it requires adopting the basics of cloud native security audits and moving from rudimentary RBAC to more advanced policy and tagging controls.
You can learn more about automated, continuous monitoring for compliance in the e-book Continuous Monitoring & Compliance in the Cloud.
Feature image via Pixabay.
At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: feedback@thenewstack.io.
