The Ops Community ⚙️: Blink Ops

10 Essential Security Policies to Enforce That Don’t Get Covered in SOC 2 and ISO 27001

Ashlyn Eperjesi — Fri, 29 Sep 2023 17:47:30 +0000

Today’s growing security threats prove that it’s critical for businesses to protect sensitive data and ensure robust cybersecurity practices. As 78% of organizations anticipate annual increases in regulatory compliance requirements, it’s no wonder there’s growing adoption of data and security standards. Two common standards that teams turn to are SOC 2 and ISO 27001 compliance.

What is SOC 2 Compliance?

SOC 2 compliance is a recognized standard that verifies the controls and security practices of organizations that handle sensitive customer data. It ensures the confidentiality, integrity, and availability of that data. A third party performs an independent audit of an organization's policies, procedures, and technical controls based on the Trust Services Criteria.

Achieving SOC 2 compliance showcases a steadfast dedication to safeguarding data security and privacy. It offers customers and partners the assurance that their valuable data is fortified, particularly in industries where data protection is paramount.

What is ISO 27001?

ISO 27001 is a well-known international standard for information security management systems (ISMS). It provides a systematic approach for organizations to establish, implement, maintain, and continually improve their information security (InfoSec) processes. ISO 27001 encompasses a comprehensive set of controls and risk management practices that span various critical areas. These include risk assessment, security policies, asset management, access control, incident response, and compliance.

Obtaining ISO 27001 certification showcases an organization's dedication to safeguarding its information assets. It instills trust in customers, partners, and stakeholders, confirming the presence of robust security measures.

Additional Security Policies to Consider

While compliance controls like SOC 2 and ISO 27001 establish a solid foundation, companies should consider implementing additional policies to enhance their security posture. Here are 10 specific policies that are crucial to enforce and go beyond the scope of SOC 2 and ISO 27001 compliance controls.

Password Complexity and Rotation Policy: Mandate a policy that enforces strong password complexity, including a combination of uppercase and lowercase letters, numbers, and special characters. Additionally, implement a password rotation policy that requires users to change their passwords at regular intervals to mitigate the risk of unauthorized access.
Two-Factor Authentication (2FA) for All Users: Require the use of two-factor authentication (2FA) by all users - employees and clients alike - to access company systems and applications. This additional layer of security significantly reduces the risk of unauthorized access, even if passwords are compromised.
Privileged Access Management: Implement a policy that restricts privileged access to critical systems and data. Only authorized personnel should be granted privileged accounts. Strict monitoring and auditing of their activities should be conducted to prevent misuse and unauthorized access.
Data Loss Prevention (DLP) Policy: Ensure the protection of sensitive data by implementing data loss prevention measures. This includes monitoring and controlling data transfers, encrypting data at rest and in transit, and implementing robust data backup and recovery procedures.
Acceptable Use Policy for Bring Your Own Device (BYOD): Define a policy that governs the acceptable use of personal devices within the corporate network. This policy should outline security requirements such as device registration, mandatory security applications, and encryption protocols to mitigate risks associated with BYOD practices.
Social Engineering Awareness and Prevention: Educate employees about social engineering techniques and establish guidelines to recognize and report potential threats. Regular training sessions, phishing simulations, and awareness campaigns can help employees stay vigilant against social engineering attacks.
Vulnerability Management Policy: Develop a policy that outlines procedures to identify, assess, and remediate vulnerabilities in the organization's systems and applications. This includes conducting regular vulnerability scans, prioritizing and patching identified vulnerabilities, and implementing a process for continuous vulnerability monitoring.
Incident Escalation and Response Time Policy: Establish clear escalation paths and response time expectations for security incidents. This policy should define roles and responsibilities, escalation thresholds, and predefined incident response procedures to ensure timely and effective incident management.
Secure Disposal and Destruction of Data: Implement a policy that outlines proper procedures for the secure disposal and destruction of sensitive data and storage media. This includes guidelines for data wiping, physical destruction, and proper disposal techniques to prevent unauthorized access to discarded information.
Security Awareness Training for Third Parties: Develop a policy that mandates security awareness training for third-party vendors and partners with access to the company's systems and data. This training should cover security best practices, incident reporting protocols, and contractual obligations to ensure that third parties adhere to high cybersecurity standards.

While SOC 2 and ISO 27001 compliance controls provide a baseline for cybersecurity, companies must go beyond these frameworks to strengthen their defenses. By enforcing these 10 specific policies, organizations can significantly enhance their cybersecurity posture and protect their valuable assets from evolving threats.

These policies address critical areas such as password management, access controls, data protection, incident response, and training, helping companies establish a robust security foundation in an increasingly complex digital landscape.

Security Automation Copilot for Your Compliance Team

Implementing the right security policies is essential for any business, but with so many regulations to keep track of, it can be hard to stay on top of all your compliance demands. That's why automation tools like Blink Copilot generative AI make it easy to automate compliance workflows.

By leveraging a security automation copilot, you can ensure that no important policy gets overlooked while keeping up with ever-changing regulatory requirements.

Aligning Your AWS Account with the FFIEC Cybersecurity Standards

Patrick Londa — Wed, 05 Jul 2023 20:45:07 +0000

Companies in the banking and finance industry must adhere to high security standards since they are high-value targets for bad actors.

Industry-specific organizations like the Federal Financial Institutions Examination Council (FFIEC) have established guidelines to help companies ensure compliance with applicable laws and regulations.

In this guide, we’ll show you how to check if your AWS account adheres to the cybersecurity standards set forth by the FFIEC using automations in Blink.

Understanding the FFIEC Cybersecurity Standards

Established in 1979, the Federal Financial Institutions Examination Council (FFIEC) is a U.S. government interagency body of five organizations working together to ensure the safety and soundness of the banking system.

The FFIEC coordinates common standards for banks and develops uniform guidelines and examinations for all financial institutions. It also releases tooling, like the Cybersecurity Assessment Tool (CAT), to help financial institutions evaluate their cybersecurity risk and develop appropriate controls. The CAT is a document that provides a framework and guidance, but it does not interactively assess an AWS account for compliance.

FFIEC Cybersecurity Guidance for AWS

An audit of an organization's AWS environment is a critical part of FFIEC compliance requirements. AWS provides the tools and services necessary for financial institutions to adhere to FFIEC regulations, but each organization must ensure that its environment meets the specific requirements of the FFIEC.

AWS provides operational best practices for FFIEC compliance, including a list of control IDs, AWS configuration rules, and guidance.

Here are some examples of controls that organizations using AWS must follow to meet the FFIEC guidelines:

An inventory of organizational assets is maintained.
An information security and business continuity risk management function exists within the institution.
The risk assessment identifies internet-based systems and high-risk transactions that warrant additional authentication controls.
Information security threats are gathered and shared with applicable internal employees.
Audit log records and other security event logs are reviewed and retained in a secure manager.

For each of these controls, there are a few to several configuration rules in AWS that could apply to your organization, depending on the guidance.

Manually checking whether your EC2 volumes are all encrypted, your IP addresses are all private, or you have the right password policy in place could take days or weeks.

If you want to check your AWS environment for compliance quickly, you can use automation to get a comprehensive report based on these controls.

Automating FFIEC Compliance for AWS with Blink

With one automation in Blink, you could quickly scan your AWS environment to check your FFIEC compliance against the controls and generate reports with the findings.

Blink Automation: Federal Financial Institutions Examination Council Compliance Report for AWS

When this automation runs, it executes the following steps:

Generates a Cyber Risk Management and Oversight Report.
Generates a Threat Intelligence and Collaboration Report.
Generates a Cybersecurity Controls Report.
Generates an External Dependency Management Report.
Generates a Cyber Incident Management and Resilience Report.
Sends Report results to a specified email.

You could set this automation to run weekly, monthly, or quarterly so you can validate that you are maintaining your compliance over time.

You may also have other compliance checks you need to run beyond this one with the Financial Federation Institutions Examination Council guidelines. What about SOC, ISO, or PCI compliance?

There are over 7K pre-built automations in the Blink Library that make it easy to gauge your environments against industry standards.

To start streamlining your compliance and security checks today, you can get started by signing up for a free trial or guided demo of Blink.

Introducing Blink Copilot: Generative AI for Security Workflows

Patrick Londa — Wed, 31 May 2023 19:27:58 +0000

Today, we’re announcing Blink Copilot, the first ever generative AI for automating security and IT operations workflows. This innovative tool makes it possible for any security operator to generate no-code workflows using a simple prompt.

When Blink was founded in 2021, we knew security teams needed a better way to automate internal workflows. Low-code platforms had already transformed business operations for CRM and marketing, and it was only a matter of time before low-code solutions enabled security teams to automate their own workflows across their stacks.

Recent advancements in large language models (LLM) and generative AI have supercharged our mission, finally making true no-code automation possible. That’s why today, we’re excited to announce Blink Copilot, the first ever generative AI for security workflow automation.

Blink Copilot enables security teams to generate any simple or complex workflow, instantly. Generative AI makes it possible to build workflows without writing code or needing to be an expert in target applications.

The Critical Need for Security Automation

According to the 2022 (ISC)² Cybersecurity Workforce Study, there are over 3.4 million open security jobs and too few skilled security operators to fill them. Meanwhile, cybersecurity breaches in 2022 were more costly than ever before.

With such high stakes and a massive skills gap, security automation is necessary for organizations to defend against the massive volume of attacks enterprises face on a daily basis.

Blink Copilot empowers teams of any size to build any no-code, low-code, or code security automation using generative AI. With Blink Copilot, security and IT operators of all skill levels can now leverage AI to increase productivity and deliver workflows to help protect their organizations.

Blink Copilot unlocks unparalleled automation capabilities for security teams. Security automation projects that once took months are now built in seconds using Blink Copilot.

Automate Security Beyond the SOC

Blink Copilot empowers security teams to automate any operations workflow, effortlessly. Security practitioners regardless of skill set can automate any operational task or security workflow using a simple text prompt.

Blink Copilot can help security teams automate workflows for:

SOC & Incident Response
Cloud Security
IT & SaaS Security
Identity & Access Management
Governance, Risk & Compliance

Using Blink Copilot, security teams can finally automate workflows beyond the SOC. Blink customers get out-of-the-box automations for popular security use cases and powerful automation capabilities backed by the robust Blink platform.

Our internal team at Blink Ops has already generated over 7,000 workflow automations. Now with Blink Copilot, we’re empowering any team to build no-code, low-code, or code security workflow automations using generative AI.

Powerful No-Code Security Automation

Blink Copilot is backed by the most powerful no-code security automation platform ever built.

Key features of the Blink platform include:

Blink Copilot: The first ever generative AI for automating security and IT operations workflows
Low-Code Editor: Drag-and-drop user interface that makes it easy for security teams to customize workflow automations
Automation Library: 7,000+ security workflow automations built by the Blink community
Self-Service Portal: Shift-left service requests by making automated workflows available in a self-service portal or interactive Slack/Microsoft Teams app

Blink was designed for enterprise security teams, offering robust platform features like secure workspaces, on-prem runners, and multi-tenant support for MSPs and MSSPs.

Blink is committed to upholding the highest grade of industry security standards, including SOC 2 Type 2, GDPR, ISO 27001 compliance. Blink can also help teams leverage no-code automation to achieve compliance across their own organizations.

Learn more about the Blink platform and technical capabilities in the Blink documentation.

Get Started with Blink Copilot

Blink Copilot completely transforms how security teams will automate simple and complex workflows.

Security teams can take advantage of Blink Copilot today to shift-left internal workflows. Along with 7,000 out-of-the-box automations for common security use cases and powerful automation capabilities backed by the robust Blink platform, enterprise security teams can finally achieve operational excellence across their entire stack.

For more information on Blink Copilot, visit the Blink Ops website.

How to Find and Update Public EC2 AMIs in AWS

Patrick Londa — Fri, 05 May 2023 19:30:54 +0000

Resources in AWS should only be accessible to users who require them to complete tasks. If this principle of least privilege isn't followed, you increase the risk for data leakages or unauthorized access.

If you have EC2 AMIs that are publicly-shared for example, they are available to any AWS account and may contain sensitive data about your organization such as passwords, SSH keys, and configuration details.

In this guide, we will explain how to find and restrict publicly-shared AWS EC2 AMIs so you can ensure that sensitive information about your applications is not exposed.

Understanding AMIs for AWS EC2

An Amazon Machine Image (AMIs) is an image that enables you to easily launch Amazon Elastic Compute Cloud (EC2) instances with the necessary requirements preconfigured.

Each AMI includes instructions for block device mapping, launch permissions, and a root device volume, either backed by the EC2 instance store or at least one Amazon Elastic Block Store (EBS) snapshot.

You can use an AMI to launch single instances or multiple servers in a cluster. For example, if you are launching a web server that handles a large volume of traffic, you can use an AMI to deploy it quickly. You can also launch multiple instances in the same cluster and configure them to work together.

These AMIs can be shared with specific users, giving them access to the same configurations and settings. If they are publicly-shared, AMIs can reveal sensitive information about how your instances function.

How To Find Any Public AMIs in AWS

Since AWS EC2 AMIs are publicly shared by default, it's easy to miss if you haven't taken the time to check your settings. Luckily, there are two ways to check whether your AMIs are publicly shared. You can use the Amazon EC2 Console or the AWS CLI, depending on your AWS environment.

Using the AWS Console:

This method is the most straightforward way to check if your AMIs are publicly shared. Follow these steps:

Log in to the AWS Management Console.
Select EC2 from the list of services.
Click AMIs in the left sidebar menu under the IMAGES section.
To see all the public AMIs, use the first filter in the AMI list and choose Public Images.
To check individual AMIs, select one and scroll down to the Permissions section and check the current permissions. If the selected AMI is publicly shared, the EC2 dashboard will display the following message, "This image is currently Public" in the Permissions section.

Using the AWS CLI:

You can also use the AWS Command Line Interface (CLI) to check whether your AMIs are publicly shared. This process is a bit more complex, but here's how it works:

Run the following describe-images command:

aws ec2 describe-images --executable-users all

The command will return a list of all the publicly shared AMIs in your account. If the command returns images with the Public parameter value of "true" then the AMI is publicly accessible.

For instance, the AMI in question is publicly shared if the output is something like this:

{"Images": {"ImageId": "ami-1234abcd", "Public": true } }

Now that you have identified public AMIs, next you can update them to make them more secure.

Changing Public AMIs to Private AMIs in AWS

You can update public AMIs to restrict access using either the AWS Console and CLI.

Using the AWS Console:

Log in to the AWS Management Console again and select EC2 from the services list.
Select the AMI you want to make private from the list of AMIs in the IMAGES section.
Head to the Permissions tab from the bottom bar menu on your dashboard. Click on Edit AMI Permissions.
Then select Private and Save changes to make the AMI private. The Permissions tab will now display the following message, "This AMI is not shared with any other accounts."

Using the AWS CLI:

Run the following modify-image-attribute command to make an AMI private:

aws ec2 modify-image-attribute 
    --image-id ami-1234abcd 
    --launch-permission "{\"Remove\":[{\"Group\":\"all\"}]}"

This will immediately make the AMI private while preserving all its existing permissions.

To double-check, you can list the attributes of the image by running the following describe-images command for the AMI with the id “ami-1234abcd”:

aws ec2 describe-images --image-ids ami-1234abcd

The output should now display the Public parameter as false as shown here:

{"Images": { "ImageId": "ami-1234abcd", "Public": false}}.

Now, you have successfully secured your non-compliant AMI.

Automating AWS Permission Checks for EC2 AMIs with Blink

It isn’t hard to find and secure public AMIs, but it can be time-consuming if you have many that need to be addressed or you want to check this on a regular basis.

How do you ensure that you don’t have overly-permissive AMIs at any given time? If you are only doing this task with CLI commands or steps in the console, you will need to context-switch to oversee each step.

With an automation platform like Blink, you can run this automation to identify and notify your team of new public AMIs so you can maintain consistent compliance.

Blink Automation: Ensure EC2 AMIs are Not Shared Publicly in AWS

This automation in the Blink library executes the following steps:

Checks if there are any publicly-shared AWS EC2 AMIs.
Sends a report to a specified email address.

This is a simple automation, which makes it easy to customize for your organization’s needs. For example, you can add actions to update the settings of non-compliant AMIs with just an approval via Slack.

This automation and 5K more are available for you to use right away from the Blink library. Instead of manually implementing best practices with the AWS console or CLI, these ready-to-use automations enable you to set and enforce policies across your organization or teams.

You can also build custom automations to match your organization’s unique use cases, whether you want to schedule a task, run steps based on an event in a certain tool, or share a self-service application for your coworkers to use.

Start a free trial of Blink today or schedule time with us to see more.

How to Search for an IOC Across Devices in CrowdStrike

Patrick Londa — Sun, 09 Apr 2023 16:39:43 +0000

When malware is detected on one of your organization’s devices, it will have characteristics called Indicators of Compromise (IOCs), such as certain hash values, urls, or IP addresses.

You can use these IOCs to look across your organization’s devices to identify lateral movement associated with an attack.

In this guide, we’ll show you how to use CrowdStrike to detect if IOCs associated with malware are present on any other devices at your organization.

Searching for an IOC Across CrowdStrike Hosts

You can search for IOCs on other devices either by using the CrowdStrike Console or by using the CrowdStrike API.

Using the CrowdStrike Console:

1: First log in to the CrowdStrike Falcon Console.

2: Open the left-hand menu and select Investigate.

3: Depending on your IOC type, choose the related link under the Search section. For example, if you are looking for an IOC that is a domain, you can choose Bulk domains.

4: Input your IOC value and specify the time range you care about. Then click Submit.

In the results, you’ll see which hosts have observed the IOCs you’re investigating and you’ll see details on the process-level as well.

You may want to contain any additional hosts now associated with the IOC. We wrote a guide on containing hosts here. For your audit trail, you can export this data by hovering over either section and clicking the Export icon.

Using the CrowdStrike Falcon API:

The platform also offers an API which allows administrators to easily programmatically manage their sensors. You can use the endpoint that geographically aligns with your specific CrowdStrike account:

US-1 “api.crowdstrike.com”
US-2 “api.us-2.crowdstrike.com”
US-GOV-1 “api.laggar.gcw.crowdstrike.com”
EU-1 “api.eu-1.crowdstrike.com”

In the examples we show later, we’ll use “api.us-2.crowdstrike.com”.

CrowdStrike’s API documentation is available after you log in here, and you’ll see information about how to use OAuth2 for authenticating your requests.

Before you start, you need to make an access token request, including your client ID and client secret. You’ll get an access token in response that will be valid for 30 minutes after that. The API calls you make after that initial call will include that token.

Next, make a GET request to this endpoint with IOC type and value specified:

https://api.us-2.crowdstrike.com/indicators/queries/devices/v1?type=sha256&value=XYZ

You can use the following IOC types:

sha256
md5
domain
ipv4
ipv6

You can also use the parameters limit and offset to manage pagination of results. With the response, you’ll be able to see all the resources that have observed the specific IOC.

Automatically Searching Across Devices for IOCs with Blink:

Checking if similar IOCs exist on other devices at your organization is one of many steps in responding to a security alert. While it isn’t difficult to do, it takes time and context-switching.

With Blink, you can handle this task automatically by just inputting an IOC type and value.

With these IOC inputs, this automation runs the following steps:

Searches for other devices that have observed the IOC.
Parses the results to format them into an easily readable report.
Sends the report to the relevant SecOps team member via Slack.

This is a simple automation, and that makes it easy to customize. For example, you can add this as a subflow in larger incident response automation triggered by a CrowdStrike alert.

You can also use any of the 5K automations in the Blink library, or build new ones from scratch to fit your unique needs. In Blink, there are hundreds of native integrations and thousands of actions available to make building easy.

Start a free trial of Blink today to see how easy automation can be.

How to Get User Activity From Your Azure Logs

Patrick Londa — Thu, 23 Mar 2023 18:14:47 +0000

It’s important to be able to audit user activity in Azure, whether you are dealing with a security incident or just want to fully review the actions a user has taken.

If one of your developers has their account compromised, reviewing their user activity can be a necessary task to ensure that they haven’t done anything malicious to your Azure account and resources, or exfiltrated data like access keys or secrets.

In this guide, we’ll show you how to retrieve all the activity logs for a given user in Azure to quickly assess the scope of the threat.

How to Get User Activity From Azure Logs

Azure Monitor collects and organizes all log and performance data from Azure resources, and you can access the activity logs for the last 90 days through steps in the console or CLI commands.

Using the Azure Monitor Log:

1. Open the Azure console, and navigate to the Activity log view. You can do this either by clicking into a specific resource or by searching for Azure Monitor to see all activity logs across your account.

Source: Azure documentation

2. Next, you can add the Events initiated by filter to view only the activity logs related to a specific user.
3. You can also adjust the timespan filter to specify the full duration you care about. You can also select Edit columns if there is additional information you want to view.
4. To export the logs, click on Download as CSV.

This method is relatively simple, but it does require logging in to the console and manually working through the steps. Let’s look at running this same search from the Azure CLI.

Using the Azure CLI:

If you aren’t already set up with the Azure CLI, you’ll need to install it locally. From there, you can run the az monitor activity-log list command to list and query activity logs.

Here is the format to get the activity logs for a specific user:

az monitor activity-log list --caller [USER-NAME]  
--offset [TIME-RANGE]

The offset parameter is formatted as XXdXXh, and defaults to 6h if not specified.

Here’s an example command to get the activity logs for John Smith:

az monitor activity-log list --caller john.smith@blinkops.com  
--offset 14d

You can these additional parameters to modify the results:

--start-time or --end-time: use the format of date (yyyy-mm-dd), time (hh:mm:ss.xxxxx), and timezone (+/-hh:mm).
--resource-group, --resource-id, --namespace: use this to narrow to only activities affecting those specific resource areas.
--max-events: use to change the limit of the results, the default is 50

You can see all of the options in the command documentation.

This approach is more easily repeatable than the console steps, but it requires you to remember the commands and be familiar with the Azure CLI.

With a no-code automation tool like Blink, you can run this task effortlessly.

Getting User Activity from Azure Faster with Blink

Retrieving user logs manually and adding them to a ticket could be a waste of valuable time, especially if your team is responding to a security incident.

With Blink, an automation can be triggered to pull and enrich Azure activity logs and other information for a compromised user right away.

Blink Automation: Get User Activity from Azure Logs

The automation shown above is in the Blink library and is set up as a self-service app – where a team member can specify input parameters and get all the activity logs sent to an email address.

When it runs, it executes the following steps:

1. Fetches the logs from Azure monitor for a specified email address.
2. Formats the logs for better readability.
3. Reports the results to the specified email address.

If you’re handling a security incident, you can have this flow as part of an automation that is triggered by a malware or DLP alert for a given user. That way, you have all the logs and information you need to assess the risk for your organization.

You can import this automation from the library into your account and customize it based on your organization’s needs. For example, you can drag-and-drop new actions into the canvas or set up conditional subflows.

You can build your own automation from scratch or use one of our 5K pre-built automations today.

Start a free trial of Blink today or schedule time with us to see more.

How to Verify IOCs and Enrich Your Incident Response with VirusTotal

Patrick Londa — Mon, 06 Mar 2023 19:03:01 +0000

IOCs, or Indicators of Compromise, are pieces of information that can be used to detect malicious activity on a network or system. By using a threat intelligence tool like VirusTotal, organizations can get more information about IOCs like the type of threat detected, its origin, or even which antivirus engines are detecting it.

In this guide, we'll show you how to use VirusTotal to verify an IOC and incorporate its results into an automated incident response workflow.

Verifying IOCs Using VirusTotal

When endpoint detection tools like CrowdStrike or SentinelOne detect malware, they will alert organizations and the incident will list IOCs. IOCs include such data as the IP address or domain name of a suspicious website, hashes associated with malware, and various other details related to an attack.

Using VirusTotal on a Browser:

If you are a SOC analyst and you want to know more information about the malicious website or software, you can go to the VirusTotal website. VirusTotal is a free service offered by Google which allows users to upload files, enter URLs, search IP addresses or file hashes, and scan these against the platform's antivirus databases.

Here’s an example of what you would see if you submitted a file hash value that isn’t malicious:

If you have a malicious file hash, you’ll see this information:

You’ll be able to view details like creation time, when it was first submitted, and when it was last analyzed, how it behaves, community comments, and more.

Using the VirusTotal API:

The VirusTotal API allows users to integrate their own custom scripts into the platform, enabling more advanced incident response workflows. For example, a script can be used to automatically upload suspicious files for scanning against the platform's databases.

To access the VirusTotal API, you’ll need to create an account and then you’ll have a free public API key you can use.

You can use this endpoint to get a file report:

curl --request GET \
--url https://www.virustotal.com/api/v3/files/{id} \
--header 'x-apikey: <your-API-key>'

You can use this endpoint to get a URL analysis report:

curl --request GET \
--url https://www.virustotal.com/api/v3/urls/{id} \
--header 'x-apikey: <your-API-key>'

And you can use this endpoint to get an IP address report:

curl --request GET \
--url https://www.virustotal.com/api/v3/ip_addresses/{ip} \
--header 'x-apikey: <your-API-key>'

If you review the API documentation, you may see other popular endpoints that better map to your incident & response process.

In the context of responding to an alert, you could save yourself a step by setting up a script to automatically call these endpoints with each respective piece of information and enrich your alerts.

Taking Action Based on VirusTotal Reports with Blink

When you enrich alerts with VirusTotal reports, you can save you time manually reviewing each detail. Instead of stopping at enrichment, what if you could utilize the results to kick off conditional responses?

For example, if an IOC is verified and has a high threat score, should you:

Immediately contain that device using your endpoint detection tool?
Search other devices across your organization to see if that IOC is present?
Add the IOC to your firewall and EDR blocking rules?

These might be the right steps, but if you scripted them all, you might not be able to control your automations easily at each stage.

With Blink, you can build event-based automations to facilitate incident response with conditional workflows and approval steps along the way. When a new alert is raised in an EDR like CrowdStrike or SentinelOne, you could immediately enrich that alert with reports from VirusTotal on each IOC.

Depending on the threat level, you can speed up your time-to-action with conditional response steps to fully leverage the combined power of the security and communication tools you’re already using.

You can start building a better response process with this pre-built Blink automation that verifies IOCs with VirusTotal. We have over 5K ready-to-use automations just like it in our library. By combining and customizing them, you’ll be able to create the workflows that match each security situation.

Get started with a free trial of Blink today or schedule time to see a demo.

How to Migrate from AWS EC2 Launch Configurations to Launch Templates

Patrick Londa — Tue, 24 Jan 2023 22:22:15 +0000

For EC2 Auto Scaling, AWS is currently urging all customers to switch from using launch configurations to launch templates instead.

As part of this push, starting in 2023, launch configurations do not support any new Amazon EC2 instance types released after Dec. 31st, 2022. In practice, AWS could release a more cost-effective instance type that better fits your use case, but you won’t be able to take advantage of it until you migrate from launch configurations to launch templates.

In this guide, we’ll explain the basics of launch configurations and launch templates, and show the steps for migrating them over.

Launch Configurations vs. Launch Templates

Amazon EC2 Auto Scaling groups need information to guide how to launch new EC2 instances when they scale. They rely on one source of truth; either an EC2 instance (automatically converted to a launch configuration), a specified launch configuration, or a launch template.

Launch Configurations

Launch configurations are instance configuration settings utilized by an EC2 Auto Scaling group to inform the new EC2 instances it launches. You must specify standard information when setting up a launch configuration, including the following:

ID of the Amazon Machine Image (AMI)
Instance Type
Key Pair
Security Group(s)
Block Device Mapping

For inspiration, you can use similar settings for previously launched EC2 instances if they match your use case. Once you create your launch configuration, you cannot make changes to it. You can only create a new one and update your Auto Scaling group to use the new one. If you do that, existing instances will not be immediately updated.

Launch Templates

Launch templates function similarly to launch configurations by specifying instance configuration information with similar information you would place in a launch configuration file. The major difference between launch configurations and launch templates is that you can set up multiple versions of a launch template.

Versioning launch templates lets you establish a subset of the complete parameter set. You can reuse these to set up other versions of the base launch template. For example, you can create a launch template with a defined base configuration without including an AMI or user data script.

After creating the launch template, you can add a new version with the AMI and user script for testing. You end up with two versions of the template. That means you can always have a base configuration for reference, then create new template versions as needed. It’s also possible to delete test template versions when they are no longer necessary.

Launch templates are recommended because you can access the latest improvements. Some Amazon EC2 Auto scaling features aren’t available when you use launch configurations. Launch templates also let you use newer generation features of Amazon EC2.

While parameters in launch templates are optional, you can’t add an AMI to one if you do not specify it when creating an Auto Scaling group. If you specify an AMI but leave out the instance type, it’s possible to add one or more when setting up your Auto Scaling group.

How to Migrate Launch Configurations to Launch Templates

Copying launch configurations to convert them to launch templates, you will need to use the AWS Console.

Migrating One Launch Configuration

Anyone currently using launch configurations can migrate them over to launch templates by copying them into the console.

Open the EC2 console.
Look for Auto Scaling in the navigation pane, then choose Launch Configurations.
Choose the launch configuration to copy.
Select Copy to launch template, Copy selected to set up a new template with the same name and options as your configuration.
Add the name of your current launch configuration file or a new name in the New launch template name field. The name must be unique.
Select Copy.

Migrating All Launch Configurations‍

Follow the steps below if you wish to move all your launch configurations to launch templates in the console:

Open the EC2 console.
Look for Auto Scaling in the navigation pane, then choose Launch Configurations.
Choose the launch configuration to copy.
Select Copy to launch template, Copy all to copy all your configurations within the current Region to a new launch template named after your configuration.
Select Copy.

Updating Auto Scaling Groups to Use Launch Templates

Using the AWS Console:

Navigate to the AWS EC2 console, open the navigation pane, and select Auto Scaling Groups.
Click on the check box associated with the Auto Scaling group you want to update.
In the Details tab, choose Launch configuration, then click Edit.
Select Switch to launch template, then select the appropriate launch template.
You’ll need to select a Version for the launch template. You can customize whether the Auto Scaling group uses a default version when it scales out, or uses the latest version.
Click Update to apply the changes.

Using the AWS CLI:

You can run this update-auto-scaling-group command:

aws autoscaling update-auto-scaling-group
--auto-scaling-group-name <value>
--launch-template <value>

An Auto Scaling group cannot have both a launch configuration and launch template parameter set. To update your Auto Scaling group to use a launch template instead of a launch configuration, you can include a launch template value in this command, like in this example:

aws autoscaling update-auto-scaling-group
    --auto-scaling-group-name my-asg
    --launch-template LaunchTemplateName=my-template-for-auto-scaling,Version='2'

Once you’ve migrated your Auto Scaling groups to use launch templates instead of launch configurations, you should stop creating new launch configurations and only create launch templates and new versions.

Replacing Launch Configurations Automatically with Blink

If you have several Auto Scaling groups, making these updates can be manual and time-consuming. You also can’t ensure that new launch configurations are not created and utilized in your AWS EC2 Auto Scaling groups.

With Blink, you can use a no-code automation to quickly identify Auto Scaling groups that are using launch configurations, convert those launch configurations to launch templates, and update the groups accordingly. You can also set up checks to detect new launch configurations and notify owners that they should use launch templates instead.

Create your free Blink account and migrate fully to launch templates today.

WEBINAR: 2023 CloudOps and Cybersecurity Predictions

Brad Johnson — Thu, 12 Jan 2023 00:17:10 +0000

Join the Blink team, cofounder and CTO (and Ops Community member!) @haviv, along with special guest Sarbjeet Johal for a webinar focused on cybersecurity and cloud recommended practices.

Learn bold predictions about trends in cybersecurity automation and cloud operations for 2023 from leading cloud executives. Blink’s CTO, Haviv Rosh, will be joined by cloud economist, Sarbjeet Johal, and other special guests to discuss the news and technologies that will matter most to enterprise leaders like CISOs, CTOs, and CEOs this year.

Get insights from our panel of technology executives who have led technology strategy for teams at companies like ServiceNow, Oracle, Palo Alto Networks to help you prepare for a secure and resilient New Year.

How to Enable Autoscaling for a GKE Cluster

Patrick Londa — Mon, 12 Dec 2022 22:01:40 +0000

Autoscaling is an automated, node provisioning process that scales your GKE clusters depending on their workload needs. As a result, GKE clusters with autoscaling enabled scale up their node pool to offer more workload availability when demand is high and scale down their node pool to save on costs when demand is low.

You can control your cluster’s autoscaling by specifying a minimum and maximum number of nodes. You can also choose whether to use the default, balanced autoscaling method or the optimize-utilization setting.

In this post, we’ll walk you through the basics of GKE cluster autoscaling and show you how to enable it for your node pools.

Understanding Your GKE Autoscaling Options

When you enable autoscaling, you have the ability to set guardrails and preferences:

Minimum and Maximum Nodes

One of the decisions you need to make is the minimum and maximum number of nodes, either per zone (minimum nodes, maximum nodes) or in total (total minimum nodes, total maximum nodes) across your node pools.

For a minimum, you’ll always need at least 1 node for each zone the node pool is in. The autoscaler will never scale down to zero because at least 1 node is needed to run the system Pods.

When setting a maximum, you might want to consider the implications of a dramatic scale up. For example, if you scale beyond the IP address space you have allocated, you will receive an error and no longer be able to add new nodes. Consider these types of dependencies when selecting a maximum.

Balanced vs. Optimize-Utilization

There are two types of autoscaling profiles. The default profile is balanced, which means it scales up and down with a balance between availability of resources and node utilization. For example, balanced autoscaling allows for more nodes with lower utilization so that they are available if workloads increase.

The optimize-utilization autoscaling profile by comparison prioritizes concentrating utilization in fewer nodes, which enables the removal of underutilized nodes. The result is faster scale downs and lower resource costs. If you choose this profile, you may experience performance delays when new workloads require new resources to be provisioned. Depending on your performance requirements, optimize-utilization may be a useful way to lower your GKE operating costs.

Configuring Autoscaling for an Existing Node Pool

If you want to enable autoscaling, you can start by updating your existing node pools using GCP Console or the GCP CLI.

Using the GCP Console:

In the Google Cloud console, navigate to the Google Kubernetes Engine page.
Select the cluster you want to update from the displayed cluster list, and go to the Nodes tab.
Under Node Pools, select the node pool that you want to update and click Edit.
Under Size, check Enable autoscaling.
Specify values for Minimum number of nodes and Maximum number of nodes, and click Save.

Using the gCloud CLI:

You can use the following command to enable autoscaling for an existing node pool:

gcloud container clusters update CLUSTER_NAME \
    --enable-autoscaling \
    --autoscaling-profile=PROFILE \
    --node-pool=POOL_NAME \
    --min-nodes=MIN_NODES \
    --max-nodes=MAX_NODES \
    --region=COMPUTE_REGION

Plug in your details for the cluster, node pool, and region. If you only have one node pool, you can use default-pool as your value. The region value should be your Compute Engine region, or specific zone if it’s a zonal cluster.

The --enable-autoscaling flag invokes autoscaling. You can customize your configuration with --autoscaling-profile (balanced or optimize-utilization), --min-nodes, --max-nodes, --total-max-nodes, and --total-max-nodes.

Here’s an example of enabling autoscaling with an optimize-utilization profile for the pool-1 node pool of the demo-1 cluster:

gcloud container clusters update demo-1 \
    --enable-autoscaling \
    --autoscaling-profile=optimize-utilization \
    --node-pool=pool-1 \
    --min-nodes=1 \
    --max-nodes=4 \
    --region=us-central1

Enabling Autoscaling When Creating a New GKE Cluster or Node Pool

If you are creating new clusters or node pools, you can enabling GKE autoscaling by using settings in the GCP Console or GCP CLI flags:

Using the GCP Console:

In the Google Cloud console, go to the Google Kubernetes Engine page.
To set up a new cluster, click Create. To create a new node pool, select an existing cluster and click Add Node Pool.
Specify details for your cluster or node pool. For a new cluster, click default-pool under Node Pools from your navigation pane.
Next, you need to select the Enable autoscaling checkbox. For node pools, you’ll find it under the Size section.
Modify the values for Minimum number of nodes and Maximum number of nodes according to your requirements, and click Create.

Using the gCloud CLI:

When you are creating new clusters or new node pools, you can ensure that they have autoscaling enabled by including the --enable-autoscaling flag and specifying --min-nodes and --max-nodes values.

Here’s an example of creating a new cluster with this command:

gcloud container clusters create my-cluster --enable-autoscaling \
    --num-nodes=30 \
    --min-nodes=15 --max-nodes=50 \
    --region=us-central

Here’s an example of creating a new node pool with this command:

gcloud container node-pools create node-pool-1 
    --cluster=sample-cluster 
    --num-nodes=5
    --enable-autoscaling
    --min-nodes=5 --max-nodes=15

By updating your existing node pools, and creating new clusters and node pools with autoscaling enabled, you’ll be able to ensure your clusters are able to automatically adapt to changing workloads.

Checking Whether Autoscaling is Enabled with Blink

Autoscaling can make your GKE clusters more effective and efficient. If you want to make it a standard that your organization's GKE clusters have autoscaling enabled, then you can manually enable it using the steps above. Unfortunately, that requires many manual updates and doesn’t ensure that future clusters will also have autoscaling enabled.

With Blink, you can use no-code automations to quickly check if you have any GKE clusters without autoscaling enabled. You can then send a notification to Slack on a regular basis if there are any clusters missing this setting. You can be more agile with making adjustments and getting information when you are only a click away.

Create your free Blink account and better manage your GKE clusters today.

Operational Excellence in a Cloud-Native World: No-Code Automation and DevOps

Haviv Rosh — Fri, 02 Dec 2022 17:35:53 +0000

In “What is Operational Excellence?,” the first post in this series, we defined what operational excellence means in today’s modern, cloud-native world. Consulting two popular frameworks, AWS Well-Architected and DORA’s five metrics, we determined how to appropriately measure DevOps efficiency and effectiveness. After learning from both of these frameworks, we compiled a list of speed (performance), scalability, and reliability as key indicators of operational excellence.

Today, cloud engineering teams are now responsible for managing hundreds of cloud tools and services across different environments. Getting all these cloud services to work together requires major configuration and maintenance effort. For most teams, that means manual integration projects, many dependencies, and writing glue code.

But, it doesn’t have to stay this way. No-code automation is changing how operations teams build their cloud workflows. Platforms like Blink now come with purpose-built automations for different cloud tools and services, reducing the effort required to build new workflows. In the Blink Automation Library, there are over 5000+ cloud automations available for teams to deploy today.

What Does DevOps Automation Mean Today?

The way cloud engineering teams think about “DevOps automation” has shifted over the last few years. Today, DevOps automation means more than just setting up CI/CD pipelines.

Widespread adoption of CI/CD tools has led to a misguided belief that DevOps are primarily responsible for integration and delivery workflows. But these activities all occur before a code is deployed into production. DevOps are also responsible for the reliable operations and maintenance of in-production cloud applications, involving tasks that have their own complex workflows. Many of these workflows involve manual processes that are not easily or adequately solved by CI/CD tools.

For example, how are you supposed to use Jenkins or any other CI/CD platforms to solve these kinds of problems?

AWS:

Azure:

GCP:

And that’s just considering operational tasks related to the major cloud providers. Don’t forget about identity management, security, observability, incident response, communication, and other third-party tools necessary to running business applications. The unfortunate reality is that CI/CD and IaC tools cannot run operational or business workflows because they are unable to react to events that happen in the cloud (such as new resources being created, new vulnerabilities or incidents, etc..).

Without an automation platform dedicated to managing operational workflows and business processes, DevOps engineers are left to navigate serverless/microservices architectures themselves. When it comes to building global operational workflows, manual scripts and CI/CD hacks won’t cut it for achieving reliability objectives or meeting customer SLAs.

Breaking the Cycle of DevOps Burnout Culture

Lack of a dedicated platform for maintaining cloud-native workflows transfers operational burden to DevOps engineers who must stitch solutions together manually. Workflows are slow to build and brittle to run. Updates take significant development time and effort.

Wasn’t DevOps about improving engineering culture and efficiency?

AWS states that “DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity.”

By now, many organizations have adopted the cultural philosophies and practices of DevOps. Agile planning and tools are common, along with agile-based development. But manually written scripts are still scattered in Git repositories, APIs still get manually glued together, and plugin updates are fraught processes that risk costly downtime.

Your level of commitment to DevOps philosophies isn’t enough when your tools and practices don’t support your workflows.

DevOps culture is about more than just making a commitment to DevOps methodology. It is the real experience of being a DevOps contributor on a software development team. For most teams, that means lots of stress, too much work, and mountains of distracting service requests from developers and business teams.

The daily experience for DevOps engineers is filled with:

Context-switching: Every day, DevOps engineers get notifications from monitoring tools, incident management platforms, project management tools, and communications platforms like Slack. They continuously receive urgent inbound service requests, get assigned on-call duty, and are still accountable for finishing their scheduled work. All the while, DevOps engineers must log in and out of different cloud tools, context-switching between different tasks and platforms costing significant time and cognitive overhead.
Stress and burnout: DevOps engineers experience an overall lack of control about what they’re working on day-to-day. With many demands on their time and too few skilled engineers to get everything done, DevOps practitioners are especially prone to burnout and churn. According to the DORA research team, having good team communication is a major factor for DevOps success. They found that “stable teams where information flows freely have lower levels of burnout.” Meanwhile, those affected by poor organizational communication are often the most vulnerable, as “employees from underrepresented groups reported higher levels of burnout.”
Poor knowledge transfer: Many operational processes and workflows lack proper documentation. When automations exist, they’re often only usable by the DevOps engineer who built them. Sometimes, DevOps engineers are unaware a relevant workflow already exists elsewhere in their organization and end up duplicating effort. This problem is exacerbated when employees leave the organization, taking valuable institutional knowledge with them. Meanwhile, skilled DevOps engineers are more difficult than ever to hire and retain.

Breaking the cycle of DevOps burnout culture requires being realistic about the demands being placed on DevOps teams and contributors. It’s critical that leaders establish clear expectations with teams and individual contributors up front, and continuously check in with direct reports to ensure they remain aligned on the correct objectives. Including DevOps stakeholders in decision making processes early and often ensures that hands-on operational wisdom is being considered during planning processes. Lastly, it’s important to prioritize producing complete and comprehensive documentation in order to aid knowledge transfer and reduce burnout.

Platform Engineering, Internal Developer Portals (IDPs), and Self-Service Automation

This past October, Gartner published an article on platform engineering, which is an emerging trend within digital transformation efforts that “improves developer experience and productivity by providing self-service capabilities with automated infrastructure operations.” This effort is deeply rooted in business objectives. Garter defines “the goal is a frictionless, self-service developer experience that offers the right capabilities to enable developers and others to produce valuable software with as little overhead as possible.”

Recently, we’ve seen growing popularity, both commercially and in the open source world, of what’s been termed internal developer portals (IDPs). These are user interfaces that allow developers to request services on-demand. IDPs improve internal developer experience for an organization, but they are limited in the types of workflows you can create. For example, anytime a developer needs a new development environment, they are able to request on on-demand.

Garter found that “initial platform-building efforts often begin with internal developer portals, as these are most mature. IDPs provide a curated set of tools, capabilities and processes. They are selected by subject matter experts and packaged for easy consumption by development teams. The platform team, in close consultation with the developers they support, must determine which approach is best for their unique circumstances.” However, the limitations of IDPs mean only very specific, developer-focused cloud workflows are solved.

With Blink, we decided to extend the utility of an IDP to all of an organization’s operational workflows. Using the Blink Self-Service Portal, you share automations that empower users to request permissions, provision cloud environments, onboard or offboard team members, initiate password resets, automate software installations, and many more workflows common to cloud-native teams. Blink provides a single system-of-action for DevOps engineers to build all the workflows that enable business teams and their whole organization, in addition to developers.

Blink delivers a more collaborative operational model that relevant automations are always available for internal teams on-demand. The Blink Self-Service Portal makes it easy to proactively support your coworkers, speed up business processes, and frees you up to focus on other projects.

What is Operational Excellence in DevOps?

At the end of the day, the best software engineering teams build better, faster, more reliable applications. Their internal operations workflows are a competitive advantage that helps them remain agile while scaling their business reliably.

So what do speed, scalability, and reliability truly mean from a DevOps perspective?

Speed and DevOps

Looking at outcomes, speed means being agile in response to changing customer expectations and new technologies. Businesses want to be fast to adopt and integrate with new technologies. This is a competitive advantage, where speed is critical. Integrating new cloud tools or services is costly in terms of time and effort required. Integrations are typically tedious, manual processes and require onboarding time to learn the vocabulary and nuances of a different tool or platform. Businesses who more rapidly adopt new cloud technologies will deliver new features and capabilities faster, gain better insights, and outperform competitors.

Speed also means operational efficiency. Three of the five DORA metrics are directly related to speed; Deployment frequency, Lead time for changes, and Time to restore service. Most cloud-native teams have adopted CI/CD and IaC tools in order to solve inefficiencies in these areas.

Speed also takes the form of improved SLAs for customers and mean-time-to-response (MTTR) when troubleshooting performance or security issues. Offering faster, more reliable services is a competitive advantage. Responding to incidents faster prevents outages and costly downtime. According to the DORA research team, 28% of respondents take 1-7 days time to restore service when experiencing stability issues. An additional 21% of the lowest performers take between 1-6 months to resolve an issue!

Scalability and DevOps

Scalability affects multiple different objectives in a DevOps context. From a DevOps perspective, it’s helpful to evaluate your ability to scale across three different axes:

Scalability of processes

Does your existing processes scale to accommodate increased demand or team growth?
When failures occur, is documentation readily available and actionable to resolve issues?
Is there an established process for new integrations or creating new workflows?

Scalability of infrastructure

Do you have established workflows for scaling infrastructure up or out?
Does your infrastructure accommodate rapid fluctuations in demand?
How do you manage cloud costs at scale?
Do you have processes in place to prevent unnecessary cloud spend?
What workflows are in place to ensure outages are avoided or quickly resolved?

Scalability of communications

How many communication channels does your organization use?
How difficult is it to coordinate across teams or channels?
How difficult is it to create actionable alerts for relevant stakeholders?
Do DevOps engineers know where to find relevant information?

No-code automation makes it easier to scale your cloud infrastructure, while being agile to the operational challenges of managing distributed cloud applications at scale. In a world of microservices and countless cloud tools, it’s more important than ever for DevOps engineers to leverage automation to abstract away ever increasing complexity.

Reliability and DevOps

Reliability is both an outcome, but also a predictor of organizational excellence. The DORA research team found that “both the practices we associate with reliability engineering and the extent to which people report meeting their reliability expectations are powerful predictors of high levels of organizational performance.” The authors recommend prioritizing having clear reliability goals, and making sure those goals tie back concrete and measurable reliability metrics.

Clear reliability goals help businesses create defensive value by delivering dependable services over time and establishing trust with customers. Furthermore, having clear reliability goals helps ensure better team communication and leads to less DevOps churn. Reliable operations workflows also create offensive value, by enabling businesses to achieve new, better, faster outcomes. Having clear reliability goals helps organizations reduce context-switching, leading to less burnout, happier teams, and better overall communication practices.

Additionally, by creating the processes and systems necessary to ensure reliable operations of your platform, you’re providing peace-of-mind for your DevOps and SREs that they are supporting a healthy system. While there are always bound to be outages, having clear expectations and processes for your DevOps team ensures greater reliability for your platform and applications.

Try Blink today

Blink enables DevOps, SecOps, and FinOps to achieve operational excellence by making it easy to create automated workflows across the cloud platforms and services they use every day. The impact of adopting a no-code automation platform like Blink is happier, more productive development teams and more reliable, resilient cloud operations.

The best part? The no-code future for cloud operations is available today. Sign up to create a Blink account.

How to Manually Rotate Keys in GCP

Patrick Londa — Thu, 01 Dec 2022 17:26:54 +0000

Key rotation is a critical security practice. In GCP, you can either rotate keys by enabling automatic rotation or by rotating a key manually.

Manual rotations make sense if your key is compromised or if you are modifying your application to use a different or stronger algorithm.

In this guide, we’ll show you how to manually rotate keys using the GCP console and the gCloud CLI.

Manually Rotating Keys in GCP

You will need to have permissions granted by the Cloud KMS Admin role to rotate keys in GCP. If you want to also do the re-encryption step below, you’ll need permissions granted by the Cloud KMS CryptoKey Encrypter/Decrypter role.

Using the GCP Console:

These are the steps to manually rotate keys in the GCP Console:

Open the Key Management page from the Google Cloud Console.
Select the name of the key ring that contains the key you want to create a new version for.
Select the key for which you need to create a new version.
Click Rotate in the displayed header.
Again, click Rotate in the prompt to confirm the key rotation.

Now, you’ll see a new version of your key is created and is marked as the primary key.

If you want to use a different existing key version, you can make it primary key using these steps:

Choose the key whose primary version you want to update.
Click View More in the row of your intended key.
Select Make primary version in the menu.
In the confirmation prompt, click Make primary.

If you have encrypted anything with the prior key, you’ll need to re-encrypt it with your new key, and then destroy the old key. This encryption step can only be done with the CLI and we’ll show it in the encryption section below.

Using the gCloud CLI:

To run Cloud KMS on the command line, you’ll first need to install the latest version of gCloud CLI. Once you’ve done that, you can run this command:

gcloud kms keys versions create \
    --key <KEY_NAME> \
    --keyring <KEY_RING> \
    --location <LOCATION>

You can input values for each of these parameters:

<KEY_NAME> refers to the name of the key.
<KEY_RING> refers to the name of the key ring that consists of the key you want to rotate.
<LOCATION> refers to the key ring Cloud KMS location.

Here’s an example:

gcloud kms keys versions create
    --key=bowser
    --keyring=castle
    --location=global

You can then set an existing key version as the primary version with this command:

gcloud kms keys update <KEY_NAME> \
    --keyring <KEY_RING> \
    --location <LOCATION> \
    --primary-version <KEY_VERSION>

The only new flag in this command is <KEY_VERSION> which refers to the version number of the new primary key.

Re-encrypting Data with a New Primary Key

If you have encrypted data with the prior key, that prior key can still be used to decrypt that data. If your key is compromised, your data will be insecure unless you re-encrypt it with your new primary key.

You should do this with the following gCloud CLI command:

gcloud kms encrypt \
    --key <KEY_NAME> \
    --keyring <KEY_RING> \
    --location <LOCATION>  \
    --plaintext-file <FILE_TO_BE_ENCRYPTED> \
    --ciphertext-file <FILE_TO_STORE_ENCRYPTED_DATA>

<FILE_TO_BE_ENCRYPTED> should be the local file path for reading the plaintext data.
<FILE_TO_STORE_ENCRYPTED_DATA> should be the local file path for where you plan to save the encrypted output.
If you want to verify that your encryption is now using the new primary key, you can test it by running the decrypt command.

Disabling or Destroying the Prior Key Version

Disabling or destroying a key both remove the key’s functionality. It’s important to ensure that compromised keys are disabled or destroyed.

The difference between the two outcomes is that destroyed keys are removed permanently (after their scheduled destruction date), which means that if you have anything encrypted that relies on that key to be decrypted, and that key is destroyed, you lose access to that data permanently. If you are certain that you no longer need the key, destroying it is a way to clean up your key ring and prevent a compromised key from somehow being restored.

Using the GCP Console:

In the GCP Console, you can disable and destroy a key by following these steps:

In the key ring view, click the key you recently rotated.
Next to the version of the key you want to change, you’ll see an Actions column with three vertical dots. Click on the dots.
Depending on which action you want to take, you can either select Disable or Destroy.
If you choose Destroy, you will need to type in the key name and click Schedule Destruction to confirm the action. Once you have done this, you will have fully rotated your keys and cleaned up the prior key version.

Using the gCloud CLI:

You can also disable or destroy keys with the CLI

You can use this command to disable a key version:

gcloud kms keys versions disable <KEY_VERSION> \
    --key <KEY_NAME> \
    --keyring <KEY_RING> \
    --location <LOCATION>

And you can use this command to destroy a key version:

gcloud kms keys versions destroy <KEY_VERSION> \
    --key <KEY_NAME> \
    --keyring <KEY_RING> \
    --location <LOCATION>

If you run the destroy a key version command, it will be scheduled for destruction. You can 24 hours after that to change your mind and restore the key.

Using No-Code Steps in Blink to Rotate GCP Keys

If you need to manually rotate access keys, you will need to remember each step and stop what you are working on to ensure you do it all properly. Working through these steps each time isn’t hard, but it takes time.

With Blink, you can easily create an automation that rotates access keys, re-encrypts files that are using the prior key version, and disables the prior key version with a simple click. If a key is compromised, you’ll be able to act quickly.

Blink also allows you schedule disabled keys for destruction after a certain period of time. Ensure that your keys are cleaned up while also giving your team time to validate that you no longer need the old versions.

Create your free Blink account and make it easy to rotate your GCP keys.