What is Security?

Security, in the realm of information technology and organizational management, refers to the comprehensive set of strategies, technologies, policies, and practices designed to safeguard digital and physical assets from threats, unauthorized access, damage, or disruption. The overarching goal of security is to protect the Confidentiality, Integrity, and Availability (CIA triad) of data and systems, ensuring that information is accessible only to authorized users, remains accurate and unaltered, and is available whenever needed.

In an increasingly digital and interconnected world, security extends beyond traditional IT boundaries to include physical security, operational security, and cyber security — the protection of networks, devices, programs, and data from attack or unauthorized access. Modern security is dynamic and requires a proactive approach to anticipate emerging threats, identify vulnerabilities, and enforce measures that mitigate risks.

Security encompasses everything from securing simple personal devices to protecting complex, multi-layered corporate networks, cloud infrastructures, and national critical infrastructures. It is a critical pillar for maintaining trust, regulatory compliance, and business continuity.

What are the Major Use Cases of Security?

Security measures find application across virtually every industry and aspect of digital life. Some of the major use cases include:

1. Network Security

Protecting organizational networks from intrusion, denial of service attacks, eavesdropping, and malware propagation. Techniques involve firewalls, Virtual Private Networks (VPNs), intrusion detection and prevention systems, and segmentation.

2. Data Security and Privacy

Ensuring sensitive information such as personal data, financial records, intellectual property, and trade secrets are encrypted, backed up, and accessible only to authorized users. This includes data masking, encryption at rest and in transit, and stringent access controls.

3. Endpoint Security

Securing user devices such as laptops, smartphones, and IoT devices from malware, ransomware, and unauthorized access using antivirus software, endpoint detection and response (EDR), and device management solutions.

4. Cloud Security

Addressing unique challenges posed by cloud computing environments — including data residency, multi-tenancy, and dynamic resource provisioning — through identity management, encryption, and monitoring cloud workloads.

5. Application Security

Protecting applications during development and deployment by conducting vulnerability assessments, implementing secure coding practices, and using web application firewalls (WAF).

6. Identity and Access Management (IAM)

Verifying and controlling user identities and access rights to systems, applications, and data using multi-factor authentication (MFA), single sign-on (SSO), and role-based access control (RBAC).

7. Operational Security (OPSEC)

Protecting internal processes, communications, and organizational knowledge that could be exploited by adversaries.

8. Incident Response and Forensics

Planning for and responding to security breaches, performing root cause analysis, and gathering forensic evidence to prevent future incidents.

9. Compliance and Governance

Ensuring adherence to regulations like GDPR, HIPAA, PCI-DSS, and others that mandate specific security controls and reporting standards.

How Security Works Along with Architecture?

Security is implemented through a multi-layered architecture that combines technical, procedural, and administrative controls, often referred to as Defense in Depth. This approach ensures that if one security layer is compromised, others continue to provide protection.

Key Architectural Components:

• Perimeter Security: Includes firewalls, intrusion prevention systems (IPS), and gateways that control inbound and outbound network traffic.
• Network Segmentation and Micro-Segmentation: Divides the network into smaller zones, limiting the scope of breaches and enforcing granular access policies.
• Encryption: Applies cryptographic techniques to secure data confidentiality during transmission (TLS/SSL) and storage (AES, RSA).
• Identity and Access Management (IAM): Centralized systems to authenticate users, manage credentials, and enforce authorization policies.
• Endpoint Protection: Agents and software that guard devices against malware, unauthorized access, and data leakage.
• Security Monitoring and Analytics: Security Information and Event Management (SIEM) systems collect and analyze logs and alerts to detect anomalies and threats.
• Cloud Security Architecture: Includes identity federation, encryption key management, and security policy enforcement specific to cloud platforms.
• Incident Detection and Response: Tools and teams dedicated to identifying, containing, and remediating security incidents.

Layers of Security Architecture:

1. Physical Security Layer: Controls physical access to hardware, data centers, and facilities.
2. Network Security Layer: Protects network communication paths.
3. Host Security Layer: Secures individual computers and devices.
4. Application Security Layer: Safeguards software applications.
5. Data Security Layer: Ensures data privacy and integrity.
6. User Layer: Manages human interaction through training and access policies.

Each layer employs complementary controls, policies, and technologies to build a robust security posture.

What are the Basic Workflow of Security?

Security management is a continuous process that involves several critical stages:

1. Risk Assessment

Identify critical assets, assess vulnerabilities and threats, evaluate potential impacts, and prioritize risks.

2. Policy Development

Define security policies, standards, and procedures that align with business goals and compliance requirements.

3. Implementation of Controls

Deploy technical (firewalls, encryption), physical (badges, locks), and administrative (training, audits) controls.

4. Monitoring and Detection

Use real-time monitoring, log analysis, and anomaly detection to identify potential security events.

5. Incident Response

Establish protocols for incident handling including identification, containment, eradication, and recovery.

6. Recovery and Continuity

Ensure systems and operations can resume quickly after disruptions via backups and disaster recovery plans.

7. Audit and Compliance

Regularly audit security controls and processes to ensure effectiveness and regulatory adherence.

8. Continuous Improvement

Incorporate lessons learned and evolving threat intelligence to adapt security measures proactively.

This cyclical workflow enables organizations to stay resilient in the face of evolving cyber threats.

Step by Step Getting Started Guide for Security

Step 1: Define Your Security Scope and Objectives

Start by identifying what data, systems, and processes require protection. Define clear security objectives aligned with organizational goals.

Step 2: Conduct a Comprehensive Risk Assessment

Map out assets, identify vulnerabilities, evaluate threats, and prioritize risks based on likelihood and impact.

Step 3: Develop Security Policies and Frameworks

Create formal policies covering data protection, access control, incident response, and user behavior. Adopt recognized frameworks like NIST or ISO 27001.

Step 4: Implement Security Technologies and Controls

Deploy necessary hardware and software controls, including firewalls, encryption, antivirus, and IAM solutions.

Step 5: Train and Educate Staff

Conduct regular security awareness training to reduce human errors and insider threats.

Step 6: Establish Monitoring and Incident Response Capabilities

Set up systems to detect, analyze, and respond to security events swiftly.

Step 7: Test and Audit Security Posture

Perform penetration testing, vulnerability assessments, and internal audits to identify weaknesses.

Step 8: Maintain and Update Security Measures

Continuously patch systems, update policies, and refine processes in response to emerging threats.

Researchers reported Friday that TeamTNT is using compromised AWS credentials to attack AWS cloud environments via the cloud platform’s application programming interface. The threat actors are now also targeting the credentials of 16 additional applications, including the AWS apps as well as Google Cloud credentials.

The researchers said the threat actors can now identify all identity and access management (IAM) permissions, elastic computer cloud instances, S3 buckets, CloudTrail configurations, and CloudFormation operations granted to the compromised AWS credentials.

This attack was significant because in hitting Google Cloud it represents the first time attackers have targeted IAM credentials on compromised cloud instances outside of AWS. Although it’s still possible that TeamTNT could target the IAM credentials of Microsoft Azure, Alibaba Cloud, Oracle Cloud, or IBM Cloud using similar methods, Unit 42 researchers have yet to find evidence that there has been an attack on the other cloud providers. TeamTNT first started collecting AWS credentials on cloud instances they had compromised as early as August 2020.

In a blog post, Palo Alto’s Unit 42 researchers said these latest discoveries followed the threat group having targeted Kubernetes clusters and creating a new malware called Black-T that integrates open source cloud-native tools to advance its cryptojacking operations.

Yaniv Bar-Dayan, co-founder and CEO at Vulcan Cyber said any enterprise using cloud services needs to understand that offloading compute and storage infrastructure to a cloud provider doesn’t mean offloading cloud security. Companies still need to apply a comprehensive vulnerability management and mitigation plan to all cyber resources utilized by a company, including cloud apps.

“Cloud vulnerabilities are not the same as application vulnerabilities and both require different remediation and mitigation actions to protect from organizations like TeamTNT,” Bar-Dayan said. “We agree with Unit 42 researchers and reiterate the immediate need to protect cloud infrastructure using the appropriate remediation steps common to cloud environments such as configuration changes, compensating controls, and workarounds.”

TeamTNT starts by infiltrating a public cloud environment – with AWS by far the most prevalent target, though Google Cloud was hit this time around – and builds a map of the environment which includes scraped credentials, workloads, and storage, said Oliver Tavakoli, CTO at Vectra.

“All this represents the equivalent of establishing a base camp prior to climbing a high summit,” Tavakoli said. “Then the insertion of cryptomining software begins with TeamTNT counting on the fact that target organizations won’t notice the uptick in usage charges for a while.”

Security teams are longing for automation capabilities. And, in recent years, their options have improved with Security Orchestration, Automation and Response (SOAR) and other security solutions like Security Information and Event Management (SIEM), Identity and Access Management (IAM), Endpoint Detection and Response (EDR), and Cloud Detection and Response (CDR) offering automation in a narrow capacity.

A recent RSAC blog post suggested that SOAR, because of its likeness to infrastructure as code, is equal to DevSecOps. The article points out that automation and coding are important to security teams, but DevSecOps is more nuanced than that. Though there are elements of workflow automation in SOAR, what sets DevSecOps apart from SOAR is its hyper-reliance on open source and its adoption of an agile approach.

What is SOAR?

Gartner® defines SOAR as “technologies that enable organizations to collect inputs monitored by the security operations team.” SOAR tools ingest data from SIEM systems to define incident analysis and response procedures in a digital workflow format.

What is DevSecOps?

DevSecOps is a modern process methodology typically applied to software development. The goals of DevSecOps are to increase release velocity, eliminate silos between teams, reduce frequency and impact of bugs in production releases, and move security further left in the software delivery process.

These goals are achieved in two ways. One, a cultural shift where teams work together on one platform. In other words, software-defined everything. Two, the use of continuous integration and continuous delivery (CI/CD). CI/CD is a category of software tools that integrate and push code frequently to make sure new versions of an application work. CI/CD tests all aspects of the pipeline, including security, before code is pushed to production.

Why SOAR is unlike DevSecOps

One might confuse the mechanics of SOAR with that of DevSecOps because security teams using a SOAR tool are, in a very high-minded way, embracing the spirit of DevSecOps, which is to use code to automate their work.

But, to be clear, this is where the similarity starts and ends. The two fundamental differences, outlined below, are what really set DevSecOps apart from SOAR.

(1) SOAR has limited support for open source: SOAR tools rarely integrate with open source tools because by nature they primarily integrate with third-party tools like Cisco, Exabeam, Okta or Splunk. The lack of open source integration is a huge deterrent for DevOps teams that rely heavily on open source tools like Git, Ansible and Kubernetes for their work. This impasse isolates security teams from production and discourages DevOps teams from collaborating.

(2) SOAR does not take an agile approach to deliver automation: When security teams using SOAR tools talk about automation, it is within the context of ingesting data from SIEM, managing that data and then automating incident response workflows. This is different from using CI/CD, as in DevSecOps, which allows developers to integrate their new source code, test it, push it and then deploy it to production frequently.

Especially for security teams, CI/CD allows them to iterate in an agile approach, scan the codebase or application for known security vulnerabilities, or run infrastructure and applications against security benchmarks that improve product safety and company-wide security posture.

Therefore, DevSecOps embraces open source and takes an agile approach to automation, whereas SOAR does not on both counts. However, the option for open source is actually ideal for security teams, which like the support and accountability afforded by a large community. Similarly, access to CI/CD is beneficial for security teams, which have long wanted to shift left. In other words, have Dev introduce them early into the software development process so that they can troubleshoot before code makes it to production.

Achieving agility with CI/CD, a DevSecOps focus

SOAR is exclusively a security platform whereas DevSecOps holistically addresses the needs of all teams by embracing CI/CD and open source tools. While SOAR cannot stand in for DevSecOps, DevSecOps solves pain points inherent to SOAR while also offering general-purpose automation that elevates the role and work of security.

Some security teams may be reticent to pursue a DevSecOps solution because CI/CD is traditionally heavily reliant on code. But there are plenty of low-code/no-code options these days. Ideally, teams should source a DevSecOps platform that is all-inclusive; one that contains a visual interface where all levels of coders can collaborate but also contains a powerful back end that caters to DevOps.

The threat landscape is ever-shifting. With security teams needing to do more despite a talent shortage, automation must gain traction to ease the pressures mounting in their domain. Security teams benefit greatly from CI/CD pipelines, which not only replicate and accelerate their manual capabilities but also carve out precious time needed for modernizing their daily work processes. By embracing the spirit and practices of DevSecOps, security teams can become agile through their CI/CD processes.

Why Google Cloud IAM Deserves Careful Thought

Google Cloud IAM (Identity and Access Management) is the core access-control layer for everything running on Google Cloud Platform. It enforces the principle of least privilege: every identity — human or machine — should have exactly the permissions it needs and nothing more.

As an organization scales, keeping IAM assignments accurate and auditable becomes increasingly difficult. A disciplined checklist helps teams avoid common mistakes: over-permissioning a service account, assigning project-wide roles when resource-level roles would suffice, or granting access to individuals instead of groups.

Every IAM assignment in Google Cloud answers exactly three questions. Thinking through them in order keeps your security posture tight and makes future audits straightforward.

Question 1: Who? (The Identity)

The first step is deciding which principal will receive the permission. Google Cloud IAM supports several identity types:

• Google Account — A single user identity (e.g., engineer@example.com). Used when a human needs direct access.
• Service Account — A non-human identity intended for applications, scripts, or automated tools. Service accounts can have keys or can rely on Workload Identity Federation.
• Google Group — A collection of Google Accounts and service accounts managed through Google Groups. Grants access to everyone in the group, simplifying large-team management.
• Google Workspace (formerly G Suite) Domain — Grants access to all identities within a Workspace domain. Use with extreme caution given the breadth of the grant.
• allAuthenticatedUsers / allUsers — Special identifiers that grant access to anyone authenticated or anyone at all. These are almost always inappropriate for sensitive resources.

Recommendations for Identity Selection

• Start narrow, expand as needed. Assign access to the smallest practical set of identities. It is easier to grant additional access later than to revoke over-provisioned access after a breach.
• Prefer groups over individuals. Managing a Google Group is operationally simpler than updating dozens of individual IAM bindings when team membership changes.
• Use dedicated service accounts per workload. A single service account shared across multiple tools makes it impossible to know which tool triggered which API call. Separate accounts enable accurate audit logging and targeted revocation.
• Separate automated from human identities. Service accounts with narrow, well-documented purposes are much easier to review and rotate than user accounts used for both manual and automated tasks.

Question 2: What Access? (The Role)

Permissions in Google Cloud map directly to specific Google Cloud REST API methods. A permission name follows the pattern <service>.<resource>.<verb>. For example, compute.instances.start allows the caller to issue a start command to a Compute Engine instance.

Permissions are never granted individually. They are bundled into roles, and roles are what you assign to an identity. There are three role types:

1. Primitive (Basic) Roles

The three primitive roles — Owner, Editor, and Viewer — predate the current IAM system and bundle an enormous number of permissions across every GCP service. They should be avoided in production environments. Assigning Editor to a service account that only needs to read Cloud Storage objects is a classic over-permissioning mistake.

2. Predefined Roles

Google maintains a curated library of predefined roles scoped to individual services. For example:

• roles/cloudsql.client — Includes cloudsql.instances.connect and cloudsql.instances.get, allowing an application to connect to Cloud SQL without administrative rights.
• roles/storage.objectViewer — Allows reading objects in Cloud Storage without the ability to list buckets or write data.
• roles/container.developer — Allows deploying workloads to GKE without cluster administration privileges.

Predefined roles vary significantly in breadth. Always review the full list of included permissions before assigning one, especially roles with names like Admin or Developer.

3. Custom Roles

When no predefined role matches your requirements exactly, you can create a custom role that lists only the specific permissions your workload needs. This is the most precise way to implement least privilege. For example, a deployment tool that only needs to update Cloud Run services and read Secret Manager values can be given exactly run.services.update and secretmanager.versions.access — nothing else.

Recommendations for Role Selection

• Never use primitive roles in production unless you have a specific, documented reason.
• Use predefined roles as a starting point. They are well-maintained and align with common access patterns.
• Use custom roles for automated workloads. Scripting and tools have predictable, bounded API usage — document and enumerate the exact permissions they need, then build a custom role from that list.
• Review included permissions before assigning any role. Use the GCP Console or gcloud iam roles describe <role> to see the full permission list.

# Inspect a predefined role before assigning it
gcloud iam roles describe roles/cloudsql.client

# List permissions in a custom role
gcloud iam roles describe my-custom-role --project=my-project

Question 3: Which Resource? (The Resource Scope)

After choosing an identity and a role, you attach the IAM policy to a specific resource. The resource determines the scope of the permission. Google Cloud’s resource hierarchy runs from broad to narrow:

• Organization — The root of the hierarchy. Policies here apply to everything under the organization.
• Folder — A grouping of projects, useful for department- or environment-level boundaries.
• Project — The most common attachment point. Policies set at the project level apply to all resources within the project.
• Individual resources — Many resource types (Cloud Storage buckets, Compute Engine instances, Pub/Sub topics, BigQuery datasets, etc.) support IAM policies set directly on the resource.

Each predefined role specifies the lowest resource level at which it can be granted. For example, App Engine Admin must be granted at the project level, while Storage Object Viewer can be granted on a single bucket. You can always attach a role at a higher level than the minimum, but broader attachments mean broader access.

Policies are also inherited down the hierarchy. A role granted at the organization level is effective at the project and resource levels. This makes organization- and folder-level grants powerful — and risky if misapplied.

Recommendations for Resource Scoping

• Apply the policy at the lowest appropriate level. If a service account only needs to read a single Cloud Storage bucket, bind the role to that bucket, not to the entire project.
• Use projects to group related resources. Creating a dedicated project for a specific service or environment makes it practical to assign project-level roles without accidentally exposing unrelated resources.
• Be explicit about inheritance. Document any roles granted at the folder or organization level and audit them regularly, since they affect all descendant resources.
• Audit policies with Policy Analyzer. Google Cloud’s Policy Analyzer tool can help you understand who has access to what across your resource hierarchy.

Putting It All Together: A Pre-Assignment Checklist

Before making any IAM change, run through these three questions:

Ongoing IAM Hygiene

Answering these three questions correctly at the time of provisioning is only the start. IAM hygiene requires continuous effort:

• Review IAM bindings regularly. Team membership changes, projects evolve, and tools get replaced. Stale permissions accumulate silently.
• Enable and review Cloud Audit Logs. Data Access logs capture who called which API on which resource. They are invaluable for detecting unexpected access patterns.
• Use IAM Recommender. Google Cloud’s built-in recommender analyses actual API usage and suggests removing permissions that have not been used within a rolling window.
• Automate policy enforcement with policy-as-code tools. Terraform, Config Connector, or Organization Policy constraints can codify your IAM standards and prevent drift.

Summary

Every Google Cloud IAM assignment reduces to three decisions: the identity receiving access, the role defining what that access covers, and the resource the policy is bound to. Getting all three right — and defaulting to the narrowest option in each case — is how teams implement least privilege in practice rather than just in principle.