Connect with us

Cyber Security

Red vs. blue vs. purple teams: How to run an effective exercise

Published

on

In the arsenal of cybersecurity defenses is the exercise that goes by the name of red team/blue team simulated attack. These simulations are designed to closely mimic real-world conditions. For example, one red team member might take on the role of an employee clicking on a phishing link that deposits malware on the network. The defending team members must then find this malware before it spreads across their network and infects web servers and other applications. To make things more realistic, the simulation replays real network traffic to obscure the attacks, just like in the real world.

Let’s talk about the red and blue designations. Red team members usually play the role of attackers and try to overcome security protocols. They use the same tools and techniques that attackers use, similar to how penetration testers operate but on a much broader scale.

“Red teams don’t just test for vulnerabilities, but do so using the tools, tips and techniques of their likely threat actors, and in campaigns that run continuously for an extended period of time,” wrote Daniel Miessler, a security consultant who has witnessed numerous red/blue exercises, in a blog post. “A great red team can be an early warning system to find common origins of attacks and to track an adversary’s techniques.”

John, a retired IBM architect who has worked in large IT shops, tells CSO that “threats are going to emerge that red teams will never test for. There are threats that can overwhelm blue teams and possibly put companies out of business.”

According to Cris Thomas, global lead of strategy for IBM X-Force Red consulting organization, “Some companies just think about red teams in terms of a physical security break-in.”

The blue team is composed of the defenders, modeled after internal security teams that are now found in numerous IT shops. “What makes for a great blue team is their mental state, having a proactive mindset, endless curiosity and continuous improvement in terms of detection and response,” wrote Miessler.

The red/blue dichotomy is somewhat misleading. To really conduct one of these simulations, two more teams should be involved:

  • A white team is composed of the network owners, the IT administrators who run the equipment and create the scripts for performing the simulations. Some exercises come with pre-built scripts while others build their own.
  • A gold team has the subject matter experts who are consultants to the exercises and could involve security vendor representatives, legal advisors and perform specialized tasks such as digital forensics. 

A note about purple teams

Let’s also talk about the color purple. This carries several different meanings, depending on how this team is constructed. The color gives you the idea that this is a combination of both red and blue teams, so that both can collaborate and improve their skills. This combination could mean that there are representatives from both sides working together on the exercise, or even as part of their jobs.

That may not be as effective as having the same people having both mindsets. Miessler likened this to waiters who don’t deliver food at restaurants because it isn’t their job. He has seen organizations where the red team thinks itself too elite to share information with the blue team, or they aren’t designed to interact with each other, or that IT doesn’t see both teams as part of the same effort.

Last summer, I attended the annual National Guard CyberShield event in Utah, where over the course of two weeks it conducts a simulated attack that is coordinated across 40 local Guard units. The units are split into red and blue teams with more than 800 members spread around the country. The Guard purposely schedules a “purple day” where both red and blue teams mingle with each other and collaborate to share tips and techniques.

“We know that the threat actors are collaborating way better than we are, and this gives us a chance for us to work closely with our partners and in realistic scenarios and build trust and deeper relationships,” says Lt. Col. Brad Rhodes, the officer in charge of the event. This building of trust is important because you want teams to learn from each other, rather than depend on a single analyst who may or may not be on duty or leave the Guard when an actual threat occurs. Rhodes has led six CyberShield exercises and works full time as head of IT security for Zvelo.

Walmart has both full-time internal blue and red team members. “We also periodically bring in outside blue and red team information security professionals to consult and we are starting to use a purple team approach to share our experiences. The two meet several times per month to help drive constant improvement for both teams, and we have seen fantastic collaboration between the two as they recognize they can drive more value to the organization,” says Jason O’Dell, vice president of security operations at Walmart.

Steps to design red team/blue team exercises

Here are some things to consider when designing your own exercise:

Decide what you will do in-house and what you will hire out. Do you need a specialized red team vendor? Do you already have full-time infosec staff that can act as a blue team? Can you use a pre-built cyber range that has everything set up a certain way?

Part of this decision is understanding the required skill sets for all team members. “A crucial skill for both teams is the desire to learn and be continuously curious,” says Walmart’s O’Dell.

Retired architect John agrees: “The ability to act quickly and effectively to any vulnerability is an absolute requirement these days.” He has never seen a company with a true red team. “Most of the time, this is outsourced to a consulting firm. Doing it in-house is hard, because of the difficulty in finding people with the exceptional skill levels needed for the job and then retaining them. If the red team is really effective, I can see them having a hard time growing their careers in the firm.”

Pick your simulation tools. Another way to phrase this is to decide on how realistic you want your exercise to be. Most of the time, these exercises won’t be done against production systems, so figure out what you will simulate or if you will use a cyber range (and usually not an exact replica of your running systems).

For the Guard’s CyberShield, they used the Persistent Cyber Training Exercise (PCTE) cloud-based simulation environment that was developed for the Defense Department. The CyberShield event is the largest operation conducted across this network, consuming more than 3,000 virtual machines and a petabyte of storage.

Formulate your goals. What are you trying to accomplish? Find weak spots? Shore up your defenses? Improve IT/end user collaboration? Identify working and failed security controls? The goal of these exercises is that more realism the better prepared everyone can be for the real attack, which gets back to the previous issue.

At the 2020 CyberShield, the red team built a piece of malware that eventually was posted on VirusTotal, according to one Guard participant I interviewed. “It was real enough when it then got picked up by Russian hackers which used it in the wild. Fortunately, its creator had placed a kill switch to neutralize it.”

Goals are critical, as Peter Kaloroumakis of MITRE, told me. “We see cases where red teams are able to successfully achieve their technical objectives but miss opportunities to have broader impact. Red or purple teams discover new information. It is essential they also engage infrastructure and architecture teams who develop strategic plans to improve security posture. It is easy to focus on specific configuration changes, but sometimes there are architectural changes which might address root cause issues.” 

Decide how you will collect the data from the exercise and how you will conduct your post-mortem analysis. A big part of that is reporting on the level of communication amongst your teams. Architect John says, “The biggest problem I’ve seen here is language/communications and poor teamwork. In the era of outsourcing teams can be from different locations, speak different languages and so forth. If people cannot understand each other, that is a big problem during and after the exercise.”

Pick your time frame. The timing of your exercise varies tremendously. IBM’s Thomas says, “Some companies buy a subscription service from IBM and do constant retesting of a mobile app as they are developing it, through either nightly builds or a regular milestone.”

The Guard needs two weeks every year because it is also conducting training exercises, so that participants can take COMPTIA and other certification classes in addition to running the CyberShield simulations. “We conduct multiple tabletop and threat simulation exercises each year. In addition, our Red Team runs numerous full adversarial engagements every year. Sometimes these engagements will blend together,” says Walmart’s O’Dell. The ideal situation is to continuously probe your systems, but certainly stick to a schedule and just don’t react to a failed security audit.

Designing the most effective red/blue exercise means being clear on a lot of non-technical points, as you can see. Make sure you pay equal attention to both the technical and non-technical issues.

Copyright © 2022 IDG Communications, Inc.

Source link

Cyber Security

Improving Cyber Hygiene with Multi-Factor Authentication and Cyber Awareness

Published

on

Using multi-factor authentication (MFA) is one of the key components of an organizations Identity and Access Management (IAM) program to maintain a strong cybersecurity posture. Having multiple layers to verify users is important, but MFA fatigue is also real and can be exploited by hackers.

Enabling MFA for all accounts is a best practice for all organizations, but the specifics of how it is implemented are significant because attackers are developing workarounds. That said, when done correctly – and with the right pieces in place – MFA is an invaluable tool in the cyber toolbox and a key piece of proper cyber hygiene. This is a primary reason why MFA was a key topic for this year’s cybersecurity awareness month. For leaders and executives, the key is to ensure employees are trained to understand the importance of the security tools – like MFA – available to them while also making the process easy for them.

MFA is still an important piece of the cyber hygiene puzzle

Multi-factor authentication (MFA) helps to provide extra layers of security throughout your organization. This quick verification serves as a tool that allows organizations to confirm identity before allowing users to access company data. This can look like prompting employees to use mobile tokens and/or to enter a specific code they’ve been texted or emailed before logging on to certain devices and websites. 

MFA fatigue is rising, and hackers are noticing

Even though MFA should be a basic requirement these days, it’s not a foolproof tactic. Attackers are finding new ways around this security layer with what are called MFA fatigue attacks.

As employees try to access work applications, they are often prompted to verify their identity in some way established by the IT security team. This typically involves notifications to their smartphones. Anyone who has been trying to complete their work in a timely manner knows the irritation of constantly having to take action on these notifications. This is the basis of the MFA fatigue attack.

Attackers excel at finding ways to gain entry to their chosen target, and they seem to know a good bit about human psychology. Attackers are now spamming employees with compromised credentials with MFA authorization requests – sometimes dozens of times in an hour – until they get so irritated that they approve the request using their authentication apps. Or they might assume there is a system malfunction and accept the notification just to make the notifications stop.

A simple, effective MFA strategy for long-term success

Getting MFA right is a balance between being strict enough so that the security measure maintains integrity and lax enough so that employees don’t grow tired of it and get tripped up.

Employees may grow irritated or think that MFA prompts are excessive as a result of frequently invalidating sessions. On the other hand, if too lenient, authenticated sessions can last too long, IP changes won’t result in new prompts, new MFA device enrollments won’t result in alerts, and enterprises run the risk of not being informed when, for instance, an authentication token that has already passed the MFA check gets stolen.

Most employees have never heard of MFA fatigue attacks, so they don’t know to look for or report them. In order to cope, organizations need to educate employees to make sure they’re prepared to spot these attacks.

Organizations need to place controls on MFA to lower the potential for MFA abuse. The most effective control is to not use methods that allow simple approvals of notifications – a scenario that contributes to MFA fatigue. All approvals should mandate responses that prove the user has the authenticated device. Number matching, for instance, is a technique that requires the user to enter a series of numbers they can see on their screen.

There’s also the effective one-time passcode (OTP) method of approval where the user gets information from the authentication request and has to enter it for verification. This requires a little more work on the user’s part, but it helps reduce the risk of MFA fatigue.

Another useful tool is an endpoint privilege management solution, which helps to stop the theft of cookies. If attackers get a hold of those cookies, they can bypass MFA controls. This solution is a robust layer in the protection of user credentials.

It’s important to set thresholds and send alerts to the SOC if certain thresholds are exceeded. The SOC can use user behavior analytics to create context-based triggers that alert the security team if any unusual behavior occurs. It can also prohibit user authentication from dubious IP addresses.

Outsmarting cyber criminals with the right security solutions and training

MFA prevents unauthorized access from cyber criminals, yet they have found a way to circumvent it by using its own premise of trust and authentication against users. That’s why organizations must use a two-pronged approach of educating employees about MFA fatigue attacks and setting up appropriate guardrails to reduce the likelihood of these attacks succeeding. Solutions like Fortinet’s FortiAuthenticator, FortiToken and FortiTrust Identity further protect organizations and strengthens their security posture. At the same time, cybersecurity awareness training, like Fortinet’s Security Awareness and Training service, can help ensure that employees are aware of all threat methods, as well as the importance of properly using all the security tools available to them.

Find out more about how Fortinet’s Training Advancement Agenda (TAA) and Training Institute programs—including the NSE Certification programAcademic Partner program, and Education Outreach program—are increasing access to training to help solve the cyber skills gap

 

Copyright © 2022 IDG Communications, Inc.

Source link

Continue Reading

Cyber Security

Researchers found security pitfalls in IBM’s cloud infrastructure

Published

on

Security researchers recently probed IBM Cloud’s database-as-a-service infrastructure and found several security issues that granted them access to the internal server used to build database images for customer deployments. The demonstrated attack highlights some common security oversights that can lead to supply chain compromises in cloud infrastructure.

Developed by researchers from security firm Wiz, the attack combined a privilege escalation vulnerability in the IBM Cloud Databases for PostgreSQL service with plaintext credentials scattered around the environment and overly permissive internal network access controls that allowed for lateral movement inside the infrastructure.

PostgreSQL is an appealing target in cloud environments

Wiz’ audit of the IBM Cloud Databases for PostgreSQL was part of a larger research project that analyzed PostgreSQL deployments across major cloud providers who offer this database engine as part of their managed database-as-a-service solutions. Earlier this year, the Wiz researchers also found and disclosed vulnerabilities in the PostgreSQL implementations of Microsoft Azure and the Google Cloud Platform (GCP).

The open-source PostgreSQL relational database engine has been in development for over 30 years with an emphasis on stability, high-availability and scalability. However, this complex piece of software was not designed with a permission model suitable for multi-tenant cloud environments where database instances need to be isolated from each other and from the underlying infrastructure.

PostgreSQL has powerful features through which administrators can alter the server file system and even execute code through database queries, but these operations are unsafe and need to be restricted in shared cloud environments. Meanwhile, other admin operations such as database replication, creating checkpoints, installing extensions and event triggers need to be available to customers for the service to be functional. That’s why cloud service providers (CSPs) had to come up with workarounds and make modifications to PostgreSQL’s permission model to enable these capabilities even when customers only operate with limited accounts.

Privilege escalation through SQL injection

While analyzing IBM Cloud’s PostgreSQL implementation, the Wiz researchers looked at the Logical Replication mechanism that’s available to users. This feature was implemented using several database functions, including one called create_subscription that is owned and executed by a database superuser called ibm.

When they inspected the code of this function, the researchers noticed an SQL injection vulnerability caused by improper sanitization of the arguments passed to it. This meant they could pass arbitrary SQL queries to the function, which would then execute those queries as the ibm superuser. The researchers exploited this flaw via the PostgreSQL COPY statement to execute arbitrary commands on the underlying virtual machine that hosted the database instance and opened a reverse shell.

With a shell on the Linux system they started doing some reconnaissance to understand their environment, such as listing running processes, checking active network connections, inspecting the contents of the /etc/passwd files which lists the system’s users and running a port scan on the internal network to discover other servers. The broad port scan caught the attention of the IBM security team who reached out to the Wiz team to ask about their activities.

“After discussing our work and sharing our thoughts with them, they kindly gave us permission to pursue our research and further challenge security boundaries, reflecting the organization’s healthy security culture,” the Wiz team said.

Stored credentials lead to supply chain attack

The gathered information, such as environment variables, told the researchers they were in a Kubernetes (K8s) pod container and after searching the file system they found a K8s API access token stored locally in a file called /var/run/secrets/kubernetes.io/serviceaccount/token. The API token allowed them to gather more information about the K8s cluster, but it turned out that all the pods were associated with their account and were operating under the same namespace. But this wasn’t a dead end.

K8s is a container orchestration system used for software deployment where containers are usually deployed from images — prebuilt packages that contain all the files needed for a container and its preconfigured services to operate. These images are normally stored on a container registry server, that can be public or private. In the case of IBM Cloud it was a private container registry that required authentication.

The researchers used the API token to read the configurations of the pods in their namespace and found the access key for four different internal container registries in those configuration files. The description of this newly found key in IBM Cloud’s identity and access management (IAM) API suggested it had both read and write privileges to the container registries, which would have given the researchers the ability to overwrite existing images with rogue ones.

However, it turned out that the key description was inaccurate and they could only download images. This level of access had security implications, but it did not pose a direct threat to other IBM Cloud customers, so the researchers pushed forward.

Container images can contain a lot of sensitive information that’s used during deployment and later gets deleted, including source code, internal scripts referencing additional services in the infrastructure, as well as credentials needed to access them. Therefore, the researchers decided to download all images from the registry service and use an automated tool to scan them for secrets, such as credentials and API tokens.

“In order to comprehensively scan for secrets, we unpacked the images and examined the combination of files that made up each image,” the researchers said. “Container images are based on one or more layers; each may inadvertently include secrets. For example, if a secret exists in one layer but is deleted from the following layer, it would be completely invisible from within the container. Scanning each layer separately may therefore reveal additional secrets.”

The JSON manifest files of container images have a “history” section that lists historical commands that were executed during the build process of every image. In several such files, the researchers found commands that had passwords passed to them as command line arguments. These included passwords for an IBM Cloud internal FTP server and a build artifact repository.

Finally, the researchers tested if they could access those servers from within their container and it turned out that they could. This overly permissive network access combined with the extracted credentials allowed them to overwrite arbitrary files in the build artifact repository that’s used by the automated IBM Cloud build process to create container images. Those images are then used in customer deployments, opening the door to a supply chain attack.

“Our research into IBM Cloud Databases for PostgreSQL reinforced what we learned from other

cloud vendors, that modifications to the PostgreSQL engine effectively introduced new

vulnerabilities to the service,” the researchers said. “These vulnerabilities could have been exploited by a malicious actor as part of an extensive exploit chain culminating in a supply-chain attack on the platform.”

Lessons for other organizations

While all of these issues have already been privately reported to and fixed by the IBM Cloud team, they are not unique to IBM. According to the Wiz team, the “scattered secrets” issue is common across all cloud environments.

Automated build and deployment workflows often leave secrets behind in various places such as configuration files, Linux bash history, journal files and so on that developers forget to wipe when deployment is complete. Furthermore, some developers accidentally upload their whole .git and CircleCI configuration files to production servers. Forgotten secrets commonly found by the Wiz team include cloud access keys, passwords, CI/CD credentials and API access tokens.

Another prevalent issue that played a critical role in the IBM Cloud attack is the lack of strict access controls between production servers and internal CI/CD systems. This often allows attackers to move laterally and gain a deeper foothold into an organization’s infrastructure.

Finally, private container registries can provide a wealth of information to attackers that goes beyond credentials. They can reveal information about critical servers inside the infrastructure or can contain code that reveals additional vulnerabilities. Organizations should make sure their container registry solutions enforce proper access controls and scoping, the Wiz team said.

Copyright © 2022 IDG Communications, Inc.

Source link

Continue Reading

Cyber Security

Software projects face supply chain security risk due to insecure artifact downloads via GitHub Actions

Published

on

The way build artifacts are stored by the GitHub Actions platform could enable attackers to inject malicious code into software projects with CI/CD (continuous integration and continuous delivery) workflows that don’t perform sufficient filtering when downloading artifacts. Cybersecurity researchers have identified several popular artifacts download scripts used by thousands of repositories that are vulnerable to this issue.

“We have discovered that when transferring artifacts between different workflows, there is a major risk for artifact poisoning — a technique in which attackers replace the content of a legitimate artifact with a modified malicious one and thereby initiate a supply chain attack,” researchers from supply chain security firm Legit Security said in an analysis of the issue.

To attack a vulnerable project’s CI/CD pipeline that downloads and uses artifacts generated by other workflows, attackers only need to fork the repositories containing those workflows, modify them in their local copies so they produce rogue artifacts and then make pull requests back to the original repositories without those requests having to be accepted.

A logic flaw in artifact storage APIs

GitHub Actions is a CI/CD platform for automating the building and testing of software code. The service is free for public repositories and includes free minutes of worker run time and storage space for private repositories. It’s widely adopted by projects that use GitHub to host and manage their source code repositories.

GitHub Actions workflows are automated processes defined in .yml files using YAML syntax that get executed when certain triggers or events occur, such as when new code gets committed to the repository. Build artifacts are compiled binaries, logs and other files that result from the execution of a workflow and its individual jobs. These artifacts are saved inside storage buckets with each workflow run being assigned a particular bucket where it can upload files and later download them from.

The reference “action” (script) for downloading artifacts that’s provided by GitHub doesn’t support cross-workflow artifact downloads, but reusing artifacts generated by different workflows as input for follow-up build steps are common use cases for software projects. That’s why developers have created their own custom scripts that rely on the GitHub Actions API to download artifacts using more complex filtering, such as artifacts created by a specific workflow file, a specific user, a specific branch and so on.

The problem that Legit Security found is that the API doesn’t differentiate between artifacts uploaded by forked repositories and base repositories, so if a download script filters artifacts generated by a particular workflow file from a particular repository, the API will serve the latest version of the artifact generated by that file, but this could be a malicious version generated automatically via a pull request action from a forked version of the repository.

“To put it simply: in a vulnerable workflow, any GitHub user can create a fork that builds an artifact,” the researchers said. “Then inject this artifact into the original repository build process and modify its output. This is another form of a software supply chain attack, where the build output is modified by an attacker.

The researchers found four custom actions developed by the community for downloading artifacts that were all vulnerable. One of them was listed as a dependency for over 12,000 repositories.

The Rust example

One of the repositories that used such a custom script in one of its workflows was the official repository for the Rust programming language. The vulnerable workflow, called ci.yml was responsible for building and testing the repository’s code and used the custom action to download an artifact called libgccjit.so — a Linux library file — that was generated by a workflow in a third-party repository.

All attackers had to do was fork the third-party repository, modify the workflow from that repository to generate a malicious version of the library and issue a pull request to the original repository to generate the artifact. If Rust’s workflow would have then pulled in the poisoned version of the library it would have provided the attackers with the ability to execute malicious code within the Rust repository with the workflow’s privileges.

“Upon exploitation, the attacker could modify the repository branches, pull requests, issues, releases, and all of the entities that are available for the workflow token permissions,” the researchers said.

Users need to enforce stricter filtering for artifact downloads

GitHub responded to Legit’s report by adding more filtering capabilities to the API which developers can use to better identify artifacts created by a specific run instance of the workflow (workflow run id). However, this change cannot be forced onto existing implementations without breaking workflows, so it’s up to users to update their workflows with stricter filtering in order to be protected.

Another mitigation is to filter the downloaded artifacts by the hash value of the commits that generated them or by excluding artifacts created by pull-request entirely using the exclude_pull_requests option. Legit Security also contacted the authors of the vulnerable custom artifact download scripts they found.

“In supply chain security, the focus has been on preventing people from contributing malicious code, so every time you do a change in a repository, create a pull request or do a change request, GitHub has a lot of built-in verification controls,” Liav Caspi, CTO of Legit Security tells CSO. “Somebody has to approve your code, somebody has to merge it, so there’s a person involved. What we’ve been trying to find are techniques that exploit a logic problem that any person could influence without review and I think this is one of them. If someone would have known about it, they could have injected the artifact without any approval.”

Typically, CI pipelines have workflows that run automatically on pull requests to test the code before it’s manually reviewed and if the pull request contains any artifact that needs to be built, the workflow will build it, Caspi said. A sophisticated attacker could create the pull request to get the artifact built and then delete the request by closing the submission and chances are with all the activity noise that exists in source code repositories today, it would go unnoticed, he said.

Copyright © 2022 IDG Communications, Inc.

Source link

Continue Reading

Trending

URGENT: CYBER SECURITY UPDATE