Cybersecurity has long relied on penetration testing – having experts run attack scenarios, probe applications and infrastructure, and scan for any weaknesses. It remains one of the most effective ways organizations can find vulnerabilities before attackers do. But with AI supercharging capabilities on both sides of the law, strong cybersecurity defenses are becoming less important to remaining breach-free than the speed with which organizations can identify risk, validate, and remediate it.

The expertise needed to perform pen testing, however, isn’t easily scalable to meet the burgeoning demand. Meaningful manual testing can take weeks, limiting how effectively organizations can defend against attacks as software, apps, and infrastructure change constantly. Manual testing just can’t keep up. Not only does AI enable attack activity on a massive scale, the window between a vulnerability’s discovery and its exploitation is rapidly shrinking.

Security leaders face a simple reality: it’s not enough to conduct a test. Now, organizations must be able to test their environments, frequently, and respond rapidly to any potential threat.

AI is changing what penetration testing can investigate

Used responsibly, with security tools and appropriate oversight, AI has the potential to expand what pen testing can do beyond identifying potential weaknesses. First, it can quickly assess whether the vulnerabilities it detects are exploitable, helping organizations to prioritize remediation of their weakest defenses. It can also map the extent of the weakness by investigating:

which systems or components an attacker could likely access by capitalising on it

whether relatively minor weaknesses, when combined, could create a material attack path

which data, functionality or business assets could be exposed as a result

what remediation options are available

The focus has shifted from finding isolated vulnerabilities to mapping and understanding complex paths of attack and the real-world impact they could have – capabilities that experts have but cannot scale. Frontier AI models are already able to reason across complex tasks, work with code, and support multi-step investigations, thus extending scarce human expertise.

Better testing means better prioritization

From an operational perspective, this shift could create a volume problem: automated defenses may find long lists of vulnerabilities, but not every vulnerability constitutes the same level of risk. Far more valuable is the ability to identify which vulnerabilities are 1) actually exploitable and 2) materially important, and prioritize those for testing and remediation.

AI-assisted testing can support security teams effectively prioritize limited remediation capacity by analyzing how vulnerabilities connect to:

application components

dependencies

likely attack paths

potential business impact

This offers greater visibility over the entire network, bringing clarity to exposure management, risk assessment, and exploitability, as well as the strategic advantage of faster, better-informed decisions around what to fix first.

The bigger prize is risk reduction

Two-thirds of organizations’ security operations are prioritizing AI adoption, but once cybersecurity has identified vulnerabilities, someone still needs to understand the underlying problem, work out how to fix it, implement that fix, and then validate whether it has worked. This often requires multiple hand-offs between security and development teams.

AI offers numerous capabilities that are already compressing this cycle – more than 60% of organizations report at least a 5% reduction in time-to-detect, while nearly 40% reduced their remediation time by 5% or more. By analyzing both the vulnerable code and its surrounding context, and then suggesting appropriate remediation approaches, AI not only speeds up discovery but also reduces the length of time the vulnerability remains unresolved. It is essential, however, that human security expertise remains firmly in the loop to validate the AI agents’ findings, assess the proposed remediation approach, and independently determine whether the remedy is safe, viable, and appropriate.

AI scales expertise. It does not remove the expert

The “assisted” in “AI-assisted penetration testing” is crucial – autonomous AI cannot replace penetration testers. Its ability to perform repetitive investigative work and explore multiple attack paths can certainly increase the speed, scale, and persistence of organizations’ cybersecurity operations. But it cannot replace the human expertise that provides business context, judgement, validation, and accountability, including the ability to determine how severe and material a threat truly is.

For senior leaders, therefore, questions of governance are paramount: organizations need crystal clear clarity on where AI is permitted to act autonomously, where human approval must be sought, and how AI-generated findings are validated.

From periodic testing to continuous validation

With business cycles a thing of the past in our always-on world, traditional methods of periodic penetration testing are no longer up to the job. Fortunately, AI offers the capability for more frequent testing, keeping up with the constant flux in applications, code, and dependencies to enable a continuous security-validation model that replaces occasional snapshots. This in turn shortens the feedback loop between development, security, and operations, as well as remediation and revalidation.

The effectiveness of an organization’s monitoring and remediation depends on:

how much of its environment is tested

how often it is tested

how quickly it can prioritize and fix issues

where to exert human oversight

how AI use in offensive security is governed

It’s already possible for organizations to transition to ongoing pen testing at enterprise scale thanks to AI. The next step is ensuring execution keeps pace with modern software development and AI-enabled threats.

Contact our cybersecurity specialists to explore how AI-assisted testing can help strengthen your resilience and reduce cyber risk.

About the author

Joshua Welle

Vice President, Global Head of Cybersecurity Portfolio

Joshua is a seasoned cybersecurity and national security expert with over 20 years of management consulting and operational experience. He advises CIOs and CISOs on cybersecurity strategy and digital transformation, delivering high-impact programs that drive organizational change. A prolific writer on digital strategy and leadership, Joshua is widely recognized as a thought leader in the field. A retired U.S. Navy Commander, he is a member of the Council on Foreign Relations and Truman National Security Project and holds advanced degrees from Harvard and the University of Maryland.

We often treat human oversight as the safety net for AI.

Let the AI prepare the recommendation and propose the action, and then put a human in the loop to approve it.

Problem solved.

Except there is one uncomfortable question:

What happens when the human stops reviewing and just starts clicking?

As AI agents take more actions, the number of decisions requiring human approval can grow quickly. A person who receives one unusual request may examine it carefully. A person who receives hundreds of similar requests every day may not.

At some point, “human in the loop” can become human just clicking approve.

The assumption sounds reasonable: humans provide judgement, context, and accountability that AI lacks. But simply adding a person to a workflow does not guarantee any of those things.

NIST has cautioned against assuming that a human overseer will automatically provide effective governance. Human decision-makers bring their own cognitive biases, and the effectiveness of different human-AI configurations depends heavily on how roles and responsibilities are designed.

Research also shows how easily people can over-rely on automated recommendations.

In one experiment involving 292 participants, people followed algorithmic recommendations more closely than equivalent human recommendations. More importantly, when participants were able to monitor and adjust the automated recommendation, they were less likely to intervene when the algorithm made its largest errors. The researchers concluded that adding a human in the loop increased uptake of automation while decreasing decision accuracy in their experiment.

That is automation bias: the tendency to rely too heavily on automated output.

The EU AI Act explicitly recognizes this risk. For high-risk AI systems, Article 14 says people responsible for human oversight should be able to understand system limitations, correctly interpret outputs, override or reverse them, and remain aware of the tendency to over-rely on AI-generated recommendations.

In other words, the regulator does not consider the mere presence of a human sufficient. The human must actually be capable of challenging the system. In this sense, approval does not always mean a judgement has been made.

Imagine an AI agent handling procurement.

Most transactions are routine. The agent prepares an action and asks an employee to approve it.

Approve. Approve. Approve. Approve.

After hundreds of correct recommendations, another approval appears.

How carefully does the employee review number 237?

This problem becomes even harder with autonomous agents. A traditional application may require occasional approval. An agent can potentially perform hundreds or thousands of actions as it works toward a goal.

OpenID contributors have raised precisely this scalability concern: per-action approval can lead to consent fatigue and reflexive approval, undermining the control it was supposed to provide.

So perhaps the question should not be on where we can insert human approval, but where does human judgement genuinely add value? Maybe humans should manage boundaries, not clicks.

Meaningful human oversight may require a different model.

Instead of asking people to approve every routine action, organizations can define in advance what the agent is allowed to do independently and what requires escalation.

For example:

An agent may process standard transactions below a certain risk threshold.

But an unusual payment, policy exception, sensitive data access, or action above a defined financial threshold may require human review. The human then focuses attention where judgement matters rather than becoming a bottleneck for thousands of predictable decisions.

NIST’s recent work on post-deployment AI monitoring identifies scaling human-driven monitoring as an open challenge and asks how oversight should vary according to risk and use case.

That may be the more important principle.

Human oversight should be designed around risk, not around the comforting presence of an “approve” button.

Test the human in the loop, too

Before declaring a process safe because it includes human approval, ask:

How many decisions does this person need to review?

Do they have enough information to challenge the AI?

Do they understand what they are accountable for?

How often do they override the recommendation?

Would they recognize an unusual or dangerous request?

Are we measuring whether the oversight actually works?

Human oversight can be extremely valuable, but only when the human is actually overseeing.

Because, ultimately, saying “a human approved it” and “a human meaningfully reviewed it” are not the same thing.

About the author

Monika Teresik

Offer Lead, Cloud Infrastructure Services

Monika Teresik is an Enterprise Service Management expert with over 15 years of experience in overseeing operations, managing transitions, and implementing IT Service Management solutions in complex multi-supplier environments. As the Offer Lead and a member of the portfolio team, she focuses on developing innovative, customer-centric solutions powered by the ServiceNow platform to address complex business challenges.

Smart cities are often data rich but insight poor. An effective city-wide response to the increasing number of climate-related events, such as flooding and heat islands, demands better insight built on integrated data and operating models.

At a glance:

Urban resilience rests on data-interoperability – the ability to connect and use data – across multiple agencies to establish a shared operating picture

Bringing all the data together under the auspices of a single city support center can speed up a unified response to climate events

AI-powered digital twins help cities to anticipate how a climate risk event may evolve and to identify areas of immediate impact

AI agents can assist operators at every step of the incident management response – veracity check, correlation of events, dynamic action plan creation and execution, and continuous monitoring and intelligence generation

The right analytics capabilities enable city leaders to predict climate events and make faster, evidence-based risk mitigation decisions

Torrential rain has caused a river to burst its banks, flooding tunnels and blocking transport routes. Who responds? The water authority pumping out water and managing the clean-up? The transport department rerouting traffic and diverting trains? The first responders? Or all together in a coordinated manner?

Similarly, the summer heatwave has created an urban heat island. Extreme high temperatures can have an impact on public health, transport systems, workforce productivity, and more. Who takes the lead? The health authority, transport operators, or municipal authorities? And who communicates with the citizens?

In both the above climate-impact scenarios, we typically see a multi-agency response. However, while there may be well-established procedures and processes in play, each agency often focuses on its own operational responsibilities. This means that there is limited coordination across the wider system and very little data transparency between all the players.

With climate-related events on the rise, this operational and data disconnect is giving city leaders and policy makers a big headache. In the following article we offer an alternative, more connected route to managing climate risk events utilizing a centralized support center, integrated data, and AI.

What is the impact of a siloed response to climate events?

For public sector leaders getting to grips with the impact of our changing environment, a siloed response can be both costly and, crucially, life threatening.

It can lead to delayed interventions, inefficient resource deployment, duplication of effort, counterproductive actions, and reduced community resilience. Maintenance spending also rises in response to (potentially preventable) damage caused, further adding to the pressure on already over-stretched local government budgets.

Climate risk events can evolve rapidly. Ideally, the fragmented information they generate should be rapidly coordinated across public safety, transport, utilities, health, municipal operations, and community services.

Instead, however, the disconnected data sources and resulting limited situational awareness mean that operators often struggle to get a clear picture of the bigger story unfolding before them. They are also often dealing with manual coordination processes and pressure to make critical decisions with constrained resources.

How does an AI-native operating model approach help to build resilience?

Urban resilience rests on the ability to connect and interpret data across multiple agencies. An AI-native approach moves the area of impact beyond fragmented sensors, cameras, citizen reports, and agency systems to establish a correlated, unified shared operating picture.

Centralized within an operational support center, this AI-infused shared operational picture provides real-time visibility of risks, impacts, resources, and affected communities, while generating actionable insights to support faster, more informed, dynamic response actions.

With the right analytics capabilities in play, the AI-native approach also enables city leaders and policymakers to both predict climate events and make faster, evidence-based risk mitigation decisions.

What’s preventing investment in the solutions needed for a joined-up response?

Many of the available solutions are custom-built for cities. This demands a big budget, which is not readily available in most cities, especially in Europe.

For cities that have not yet invested in an integrated platform, this high cost is prohibitive, although it is less so for those cities that already have data platforms up and running. There are also concerns about how quickly it might take to build a platform capable of making interoperable data real.

AI is very much at the core of modern smart city solutions – see below. This, in itself, has prevented some cities moving ahead with rolling out new solutions. That’s because they are often still in the policy development phase with regards to data, big data, and AI, along with the ethical challenges that these bring.

Can you expand on AI’s role in this connected, smart city approach?

At Capgemini, we’ve worked with Microsoft on an innovation accelerator that uses agentic AI to continuously connect and interpret disparate data sources. This enables faster situational awareness and more confident decision-making.

With the aid of AI, cities can achieve improved cross-agency coordination, more effective use of resources, enhanced resilience, and continuously improving operations that learn from every event to strengthen future preparedness and response.

We call this the Capgemini + Microsoft AI-Native City Support Center. It enables response plans to be translated into coordinated workflows across public safety, transport, utilities, health, municipal operations, and community service – see FAQs, below, for more details.

With the aid of AI, cities can achieve improved cross-agency coordination.

How do AI and scenario planning speed up the response to climate events?

If you can use AI to predict likely climate flashpoints, you can build operating procedures to mitigate them before they occur or escalate.

Response scenarios can be built using data captured from areas identified as being prone to climate-related incidents. By combining AI agents with city digital twin capabilities, cities can anticipate how a climate risk event may evolve, identify areas of immediate impact, assess risks to vulnerable populations and critical infrastructure, and evaluate alternative response strategies before conditions deteriorate.

Scenarios can be run to evaluate how best to respond at the onset of a heat island or flooding. For example, if a weather report indicates that a significant storm is due to hit, rather than waiting until it happens, preparations can begin in advance.

In the AI-native City Support Center, AI agents correlate fragmented observations into a single incident view, providing operators with real-time awareness of risks, impacts, resources, and emerging threats. They recommend relevant operating procedures and automatically generate coordinated action plans and cross-agency workflows.

If you can use AI to predict likely climate flashpoints, you can build operating procedures to mitigate them before they occur or escalate.

How can city leaders keep down costs and speed up time-to-value?

We recognize that starting from scratch is a huge commitment. But what if your city could benefit from all the value of trusted event intelligence and a unified operating picture, without the cost and time delay of a bespoke build?

Standardization is the answer. Our AI-native transformation approach uses an as-a-service, platform-based delivery model that combines Capgemini’s domain expertise, operating model design, and interoperable, standards-based accelerators with Microsoft’s proven AI, data, and cloud technologies. It can integrate with existing open, city, or urban data platforms and domain operational systems.

This reduces the build time and cuts the cost to operate. Up-front investment is also lower because we are taking an innovative approach to delivering this solution. Rather than offering it as purely a technology product, we deliver it as-a-service:

We build and tailor the platform for you

We install the technology in your operational context

We assist in establishing your AI-native operating model and governance

We run and manage it as-a-service.

What value can cities gain from an integrated operating model?

By moving from reactive incident management to predictive and adaptive operations through an integrated operating model, city leaders can:

Achieve a single, trusted view of any climate risk event: Gain a common operating picture across agencies to improve awareness, reduce uncertainty, and accelerate response.

Shift from reactive response to predictive, AI-assisted operations: Move from responding to events after they occur to proactively predicting impacts, prioritizing resources, and planning interventions.

Orchestrate the entire city response while maintaining sovereign control: Improve cross-agency coordination, optimize resource utilization, and strengthen resilience while maintaining digital sovereignty and regulatory compliance.

Combining data and AI for a faster, more informed, and coordinated response

Data continues to proliferate as our cities and urban areas become ever smarter and more digitally connected. This presents both an opportunity and a challenge.

Too much data residing in too many silos and different organizations can hinder a unified and collaborative response to climate events. On the other hand, bringing all the data together under the auspices of a single support center within the city has the potential to speed up a unified response to climate events.

Adding AI agents to analyze and monitor this data provides the all-important city-wide context needed to manage an impending or evolving climate risk event.

CMMC Level 2 Requirements: Complete Guide to All 110 Controls

For defense contractors and subcontractors handling Controlled Unclassified Information (CUI), CMMC Level 2 (Cybersecurity Maturity Model Certification) is the cybersecurity benchmark that matters most. Under CMMC 2.0, Level 2 aligns directly with the 110 security requirements in NIST SP 800-171and is designed to protect sensitive defense information across the Defense Industrial Base (DIB).

Organizations pursuing applicable Department of War (DoW) contracts must implement these controls, document them thoroughly, and prove compliance through either self-assessment or third-party certification depending on contract and security requirements.

This guide breaks down what CMMC Level 2 includes, how the 110 controls are organized, and what businesses need to do to prepare.

What Is CMMC Level 2?

CMMC Level 2 focuses on protecting CUI and serves as the bridge between basic cyber hygiene and advanced security maturity. Unlike CMMC Level 1, which covers only Federal Contract Information (FCI), CMMC Level 2 requires organizations to implement all 110 NIST SP 800-171 controls across 14 security domains. These security controls are not optional checkboxes. They require documented policies, operational procedures, technical safeguards, and evidence that security controls are functioning as intended.

For many contractors, CMMC Level 2 is the most critical certification tier because it applies broadly to companies storing, processing, or transmitting CUI.

What Are the 14 Control Families in CMMC Level 2?

The 110 controls are divided into 14 domains, each covering a core cybersecurity discipline:

1. Access Control (AC) – 22 Controls

Ensures only authorized users, devices, and systems can access CUI. 

Key examples: 

- Least privilege access

- Role-based permissions

- Session lock

- Remote access restrictions

- Network segmentation

2. Awareness and Training (AT) – 3 Controls

Requires personnel to understand cybersecurity risks. 

Key examples: 

- Security awareness training

- Insider threat awareness

- Role-specific security education

3. Audit and Accountability (AU) – 9 Controls

Focuses on logging, monitoring, and traceability. 

Key examples: 

- Audit log generation

- Event monitoring

- Log review

- Time synchronization

4. Configuration Management (CM) – 9 Controls

Ensures systems are securely configured and controlled. 

Key examples: 

- Baseline configurations

- Change management

- Application whitelisting

- Least functionality

5. Identification and Authentication (IA) – 11 Controls

Verifies users and devices before access is granted. 

Key examples: 

- Multi-factor authentication

- Unique IDs

- Password complexity

- Device authentication

6. Incident Response (IR) – 3 Controls

Defines how organizations detect and respond to cybersecurity events. 

Key examples: 

- Incident response plans

- Reporting

- Testing

7. Maintenance (MA) – 6 Controls

Secures system maintenance activities. 

Key examples: 

- Controlled maintenance tools

- Remote maintenance approvals

- Sanitization after repairs

8. Media Protection (MP) – 9 Controls

Protects physical and digital media containing CUI. 

Key examples: 

- Media marking

- Secure disposal

- Encryption

- Physical transport controls

9. Personnel Security (PS) – 2 Controls

Addresses personnel screening and termination security. 

Key examples: 

- Background screening

- Access revocation upon termination

10. Physical Protection (PE) – 6 Controls

Protects facilities and physical access points. 

Key examples: 

- Visitor controls

- Facility monitoring

- Escort procedures

11. Risk Assessment (RA) – 3 Controls

Requires organizations to identify and assess threats. 

Key examples: 

- Vulnerability scanning

- Risk assessments

- Threat remediation

12. Security Assessment (CA) – 4 Controls

Ensures ongoing evaluation of security posture. 

Key examples: 

- Periodic assessments

- Plan of Action & Milestones (POA&M)

- SSP updates

13. System and Communications Protection (SC) – 16 Controls

Protects networks and communications channels. 

Key examples: 

- Boundary defense

- Encryption

- Session integrity

- Split tunneling restrictions

14. System and Information Integrity (SI) – 7 Controls

Maintains system resilience against threats. 

Key examples: 

- Malware protection

- Patch management

- Flaw remediation

- Monitoring

Beyond the 110 CMMC Controls: 320 Assessment Objectives

A common misconception is that implementing 110 security controls is enough. In reality, CMMC assessments evaluate roughly 320 assessment objectives tied to those controls. This means each control may require multiple pieces of evidence, such as policy documents, technical settings, screenshots, interviews, and operational procedures.

For example, enabling MFA is not enough. Assessors may also review:

- Which users are covered

- Whether privileged accounts are included

- How enforcement is configured

- Whether documentation aligns with implementation

The Key Documentation Required for CMMC Level 2

To succeed at CMMC Level 2, documentation is just as important as technical controls.

Essential documents include:

- System Security Plan (SSP)

- POA&M

- Asset inventory

- Network diagrams

- Incident Response Plan

- Access Control Policies

- Security Awareness Records

Without strong documentation, even technically secure organizations can fail an assessment.

How SPRS Scores Impact CMMC Level 2 Readiness

Defense contractors subject to DFARS 252.204-7012 are required to assess their implementation of NIST SP 800-171 and submit their score to the Supplier Performance Risk System (SPRS).

SPRS is the Department of War’s system for recording NIST SP 800-171 assessment scores and tracking contractor compliance with DFARS requirements. Because those assessments are based on the same 110 NIST SP 800-171 security controls that underpin CMMC Level 2, an SPRS score can provide valuable insight into an organization’s current cybersecurity posture.

SPRS assessments include:

- Documenting compliance with DFARS 252.204-7012 requirements

- Measuring implementation progress against NIST SP 800-171

- Identifying security gaps and remediation priorities

- Supporting preparation efforts for a future CMMC Level 2 assessment

- Demonstrating cybersecurity maturity to DoW stakeholders

While an SPRS score is not a measure of CMMC readiness on its own, it serves as an important benchmark for organizations working toward CMMC Level 2 certification.

Self-Assessment vs C3PAO Certification: What To Know

CMMC Level 2 has two pathways:

Self-Assessment:

For select contracts with lower national security sensitivity. Requires annual affirmation and SPRS score submission.

C3PAO CMMC Assessment:

For prioritized contracts involving sensitive CUI. Requires formal third-party assessment every three years plus annual affirmation.

Most defense contractors should prepare as though third-party assessment will eventually apply.

The Common Challenges Organizations Face With CMMC Level 2

Many companies underestimate:

- Scoping complexity

- Legacy systems

- Security configuration gaps across cloud, endpoint, and identity environments

- Vendor management

- Documentation maturity

- Resource constraints

The hardest security controls are often not technical. They are operational, procedural, and evidence-based.

Practical Steps to Prepare for a CMMC Level 2 Assessment

Step 1: Define Scope

Identify all people, processes, technology, and external providers that touch CUI.

Step 2: Conduct Gap Assessment

Map current controls to NIST SP 800-171.

Step 3: Prioritize High-Risk Gaps

MFA, logging, endpoint security, and boundary protection often come first.

Step 4: Build Documentation

Develop SSP and POA&M early.

Step 5: Perform Internal Mock Assessment

Test against third-party assessment objectives, not just control statements.

Get CMMC Assessment Ready Today

If your organization is preparing for CMMC Level 2, the stakes go far beyond passing an assessment. Defense contractors across the DIB are facing increasing pressure to demonstrate strong cybersecurity practices, protect sensitive government information, and maintain eligibility for future contract opportunities.

Organizations that fail to address compliance gaps risk more than operational headaches. They risk lost revenue opportunities, delayed contract awards, increased scrutiny, and weakened trust across the defense supply chain.

CloudFit and easyCMMC help simplify the path forward with a streamlined 30-day approach designed to help organizations strengthen security posture, improve compliance maturity, and prepare for the operational and evidence-based requirements of modern CMMC assessments before engaging third-party assessment organizations.

Comments are closed

FBI Takes Down Major Phishing Operation: What Organizations Can Learn from the W3LL Platform

By Charlie Gebetsberger, Service Engineer

The FBI recently disrupted a major phishing operation known as W3LL, a cybercrime platform that enabled attackers to launch sophisticated credential theft campaigns at scale.

While the takedown represents a significant victory for law enforcement, it also serves as an important reminder that phishing remains one of the most effective attack methods used by cybercriminals today.

Organizations of all sizes should view this incident as an opportunity to evaluate their cybersecurity awareness programs, employee training efforts, and overall security posture.

What Was the W3LL Operation?

W3LL functioned as a phishing toolkit marketplace, providing cybercriminals with ready-made tools that made launching attacks easier and more effective.

Using the platform, attackers could create convincing fake login pages that closely resembled legitimate websites and business applications. Unsuspecting users would enter their credentials, believing they were accessing trusted services.

The platform enabled attackers to:

- Capture usernames and passwords

- Intercept multi-factor authentication (MFA) codes in real time

- Gain unauthorized access to email accounts, business systems, and other sensitive resources

According to the FBI, the operation was linked to more than 25,000 compromised accounts and over $20 million in attempted fraud.

The scale of the campaign highlights how phishing has evolved from simple scam emails into highly organized criminal operations designed to bypass traditional security controls.

Why This Matters to Organizations

Many companies invest heavily in cybersecurity tools, but phishing attacks continue to succeed because they target people rather than systems.

Today’s phishing campaigns are far more sophisticated than the obvious spam messages many employees learned to recognize years ago.

Modern phishing attacks often:

- Replicate legitimate login portals with remarkable accuracy

- Use urgent language to pressure users into taking immediate action

- Appear to come from trusted vendors, coworkers, or business partners

- Circumvent basic email filtering technologies

In many cases, even security-conscious employees can become victims when they are busy, distracted, or responding to what appears to be a legitimate request.

This is why phishing remains one of the leading causes of credential theft, business email compromise, and unauthorized account access.

How Employees Can Help Prevent Phishing Incidents

Technology plays an important role in cybersecurity, but employee awareness remains one of the strongest defenses against phishing attacks.

Organizations should encourage employees to adopt a mindset of verification before action.

Before Clicking a Link or Logging In

Employees should take a moment to verify that a request is legitimate before entering credentials.

Best practices include:

- Carefully reviewing website addresses for misspellings or unusual domains

- Being cautious of unexpected login prompts

- Verifying requests through a secondary communication channel when possible

- Treating urgent requests with additional scrutiny

Attackers frequently rely on urgency because it encourages users to act quickly rather than carefully.

Protect Credentials and MFA Codes

Compromised credentials remain one of the primary goals of phishing campaigns.

Organizations should reinforce the following practices:

- Never reuse work passwords on personal websites

- Use approved password managers whenever available

- Enable and maintain multi-factor authentication

- Never share MFA codes with anyone

Employees should remember that MFA codes are sensitive security credentials and should be protected just like passwords.

Report Suspicious Activity Immediately

One of the most effective ways to limit damage from phishing attacks is rapid reporting.

If something feels unusual, employees should:

- Stop interacting with the website, email, or message

- Avoid entering additional information

- Notify their IT or security team immediately

- Report suspected phishing attempts, even if they are unsure

Security teams would much rather investigate a false alarm than discover a compromised account after an attacker has gained access.

Organizations should also foster a culture where employees feel comfortable reporting suspicious activity without fear of blame or punishment.

Building a Stronger Security Culture

The W3LL operation demonstrates an important reality of modern cybersecurity: attackers do not always need to exploit technical vulnerabilities when they can exploit trust instead.

Successful security programs combine technology, employee education, and well-defined response procedures. Organizations that regularly train employees, reinforce verification habits, and encourage prompt reporting are often better positioned to prevent phishing incidents before they become major security events.

Key Takeaway

The FBI’s disruption of the W3LL phishing platform is a reminder that phishing remains one of the most persistent threats facing organizations today.

These attacks don’t rely on breaking into systems. They rely on convincing people to voluntarily hand over access.

By encouraging employees to verify requests, protect credentials, and report suspicious activity quickly, organizations can significantly reduce their risk.

When in doubt, verify before you trust, and report before it’s too late.

If your organization is looking to strengthen its defenses against phishing, credential theft, and other cyber threats, CloudFit can help. Our managed cybersecurity services provide the expertise, monitoring, and support organizations need to stay ahead of an evolving threat landscape.

Comments are closed

Dirty Frag: Understanding the Latest Linux Kernel Security Threat

By: Chris Bentkowski

Recently, security researchers identified two significant vulnerabilities, collectively known as Dirty Frag, affecting the Linux kernel. If you manage Linux servers or Kubernetes clusters, understanding these flaws is essential for keeping your environment secure.

What is “Dirty Frag”?

Dirty Frag (specifically CVE-2026-43284 and CVE-2026-43500) is a class of local privilege escalation vulnerabilities. In simple terms, it allows a low-privileged user or a malicious container to “break out” and gain full administrative (root) control over the host machine. The issue stems from how the Linux kernel handles certain types of network data, specifically “splice-backed packet fragments”. Under the right conditions, the kernel performs unsafe operations on memory that it should treat as private, leading to memory corruption.

Why it Matters for Kubernetes

In a Kubernetes environment, all containers on a node share the same underlying host kernel.

- Shared Risk: Because this is a kernel-level issue, standard pod isolation isn’t enough.

- The Breakout: If an attacker compromises a single pod, they could potentially use Dirty Frag to take over the entire node.

- High-Risk Scenarios: Clusters are at higher risk if they host untrusted workloads, are internet-facing, or are multi-tenant.

Is Your System Vulnerable?

The vulnerabilities affect a wide range of Linux kernel versions, dating as far back as 4.11 (released in 2017).

Affected Kernel Ranges:

- 4.11 up to 5.10.254

- 5.12 up to 5.15.204

- 5.16 up to 6.1.170

- 6.2 up to 6.6.137

- 6.7 up to 6.12.86

- 6.13 up to 6.18.27

- 7.0.0 up to 7.0.4

Note: Always check with your specific Linux distribution (Ubuntu, RHEL, Azure Linux) for their specific “fixed” version numbers, as many vendors backport security fixes.

How To Protect Your Environment

Security experts recommend a three-step “order of operations” to handle Dirty Frag:

- The Permanent Fix: Patching – The only permanent solution is to update your Linux kernel to a fixed version.   

For Standalone Servers: Apply vendor updates and reboot.

For Kubernetes/AKS: Perform a node image upgrade to ensure every worker node is running a patched VHD/image.

- Temporary Shielding: Module Blocking – If you cannot patch immediately, you can temporarily reduce your risk by blocking the specific kernel modules associated with the vulnerable paths: esp4, esp6, and rxrpc. 

The Catch: This only works if these features are compiled as loadable modules. If they are built directly into the kernel, this mitigation will not work.

Automation: Many teams use a DaemonSet in Kubernetes to automatically apply these module blocks across every node in a cluster.

- Defense-in-Depth: While waiting for patches, you can shrink your “attack surface” by: 

Minimizing the use of privileged containers.

Restricting pods from using hostNetwork or hostPID unless absolutely necessary.

Enforcing strict Pod Security Admissions.

Summary Checklist

- Identify if your nodes are running vulnerable kernel versions.

- Prioritize patching or reimaging nodes to a fixed baseline.

- Validate that updates were applied to existing nodes, not just new ones.

- Monitor for the presence of the esp4, esp6, and rxrpc modules if you aren’t using them.

How CloudFit Can Help

Keeping Linux environments secure requires more than simply applying patches. Organizations need visibility into vulnerable systems, a clear remediation plan, and confidence that updates are being deployed consistently across servers, clusters, and cloud environments.

CloudFit helps organizations identify security risks, manage vulnerability remediation, secure Kubernetes and cloud workloads, and maintain a strong cybersecurity posture through managed security and infrastructure services.

If you’re unsure whether your Linux servers, AKS environment, or Kubernetes clusters are affected by Dirty Frag, our team can help assess your exposure, validate your patch status, and implement security best practices to reduce risk.

Contact CloudFit today to learn how we can help strengthen your infrastructure against emerging threats and keep your environment secure.

References:

Comments are closed

The Mission Is Bigger Than CMMC: CloudFit’s Perspective on the Recent CMMC Phase II Pause

The recent Department of War announcement has understandably created questions across the Defense Industrial Base. While the implementation timeline for portions of CMMC may be changing, the mission itself has not.

The reality is that more than 220,000 organizations across the DIB are entrusted with protecting CUI and supporting our nation’s security. That responsibility has not been paused. Cyber threats have not been paused. The obligation to safeguard sensitive information under DFARS and NIST requirements has not been paused.

If anything, this moment presents an opportunity to ask a more important question.

Rather than focusing solely on compliance deadlines or certification milestones, we should be asking how we make meaningful cybersecurity achievable for every organization supporting our warfighters. A compliance requirement alone will never secure the DIB. True security comes from making secure environments, managed services, and proven cybersecurity outcomes accessible, repeatable, and affordable enough that organizations of every size can adopt them.

For too long, many companies have been forced to choose between expensive custom implementations, delaying security investments, or hoping they can achieve compliance on their own. That model does not scale to the size of the DIB, nor does it strengthen our national security posture.

At CloudFit, we believe there is a better path.

Our vision has never been limited to helping organizations pass an assessment. Assessments are important, but they are a milestone… not the mission. Our mission is to help mission-critical organizations build secure, resilient environments that protect sensitive information every day while positioning them for whatever compliance requirements exist tomorrow.

easyCMMC represents one part of that vision. It demonstrates that organizations do not have to sacrifice security for affordability, nor should compliance require months of uncertainty, excessive consulting costs, or unnecessary operational burden. By delivering standardized, managed cybersecurity outcomes, we believe organizations can achieve stronger security while dramatically reducing the barriers that have historically prevented widespread adoption.

This strategic pause provides an opportunity for industry and government to continue an important conversation. Not simply about when organizations should be certified, but about how we collectively secure the DIB for the long term.

CloudFit remains more optimistic than ever about that future.

We believe protecting our nation’s defense supply chain requires scalable, high-value, low-cost cybersecurity solutions that organizations can actually implement, not just audit against. We remain committed to helping our customers protect CUI, strengthen their cybersecurity posture, and prepare for whatever direction the Department of War ultimately takes.

The objective has always been bigger than CMMC.

The objective is securing the DIB.

Comments are closed

How to Understand Your DoW Contract’s CMMC Requirements

Understanding your cybersecurity obligations starts with your contract, not the headlines.

The recent Department of War announcement pausing portions of the CMMC rollout left many contractors asking the same question:

“What should we do now?”

For some, the instinct has been to wait for more guidance. Others have assumed cybersecurity requirements have been put on hold altogether.

The reality is much simpler.

Now is the perfect time to take a closer look at your contracts and understand what they actually require.

At CloudFit, one of the biggest misconceptions we see isn’t that organizations misunderstand CMMC. It’s that many don’t fully understand the cybersecurity requirements already written into the contracts they’re performing today.

Before worrying about assessments, certifications, or technology, start with the document that defines your obligations.

Your Contract Determines Your Requirements

Cybersecurity doesn’t begin with an IT project.

It begins with your contract.

Every DIB contractor’s environment is different because every contract is different.

Some organizations only need to securely receive, review, and transmit Controlled Unclassified Information (CUI). Others may be required to process engineering drawings, CAD files, software code, or other sensitive data throughout their daily operations.

The important thing is understanding which situation applies to your organization.

We’ve worked with companies that initially believed every employee, every application, and every workflow needed to fall inside a compliant environment. After reviewing how they actually handled CUI, we discovered their required scope was much smaller.

On the other hand, we’ve also worked with organizations whose contracts required specialized engineering or development workflows that absolutely did need to be included.

The difference wasn’t the technology.

It was the contract.

Start by Looking for DFARS Requirements

One of the first things to identify is whether your contract contains Defense Federal Acquisition Regulation Supplement (DFARS) cybersecurity requirements, particularly clauses like DFARS 252.204-7012.

These clauses establish expectations for protecting CUI shared with contractors.

If your contract includes these requirements, your organization should understand how CUI is received, stored, processed, and transmitted throughout your business.

That doesn’t automatically mean every system you own needs to become part of your compliant environment.

It means you need to understand where CUI actually exists.

Don’t Overlook Flowdown Requirements

Even if you don’t contract directly with the Department of War, cybersecurity requirements may still apply.

Prime contractors frequently “flow down” security requirements to subcontractors performing work under the contract.

We’ve spoken with many organizations that assumed compliance requirements didn’t apply to them because they weren’t working directly with the government.

In reality, those obligations were already included in agreements with their prime contractor.

If you’re supporting a prime, don’t stop reading after the statement of work. Make sure you understand any cybersecurity requirements that have been flowed down to your organization.

What Actually Needs Protection?

One of the most common conversations we have sounds something like this:

“We need engineering software.”

“We need CAD.”

“We need specialized development tools.”

Sometimes that’s true.

Sometimes it isn’t.

The first question shouldn’t be, “What software do we need inside our compliant environment?”

It should be, “What types of CUI is our contract going to include?”

For many organizations, the answer is surprisingly straightforward.

They need a secure place to receive contract documents, communicate with customers, review technical information, and send responses back to the government or a prime contractor.

Others genuinely need additional applications because they’re actively creating or modifying CUI as part of their work.

Understanding that distinction is one of the most important parts of correctly scoping your environment.

Ask These Five Questions

Before making technology decisions, ask yourself:

- Where do we receive CUI?

- Who needs access to it?

- Where is it stored today?

- Do we modify or create CUI as part of our work?

- What does our contract actually require us to protect?

These questions often uncover that an organization’s cybersecurity needs are very different from what they initially assumed.

The CMMC Pause Doesn’t Change Your Starting Point

While portions of the CMMC rollout have been delayed, your contract remains the foundation for understanding your obligations.

If your contract requires you to protect CUI, that responsibility hasn’t changed.

The current pause simply gives contractors an opportunity to better understand their requirements before making long-term decisions about assessments or certification.

Organizations that use this time to properly scope their environments, review their contracts, and understand how they handle CUI will be in a much stronger position regardless of how future CMMC implementation unfolds.

Start With Understanding, Not Assumptions

At CloudFit, we don’t begin conversations by recommending technology. We begin by asking questions.

What does your contract require?

How do you store, process, and transmit CUI today?

Who needs access?

What workflows actually need to be protected?

Those answers drive everything else.

Because the best cybersecurity solution isn’t necessarily the largest or most complex one. It’s the one that’s appropriately scoped for the work your organization actually performs.

Need help understanding your contract requirements or determining the right environment for your organization? Our team is here to help. Learn how easyCMMC can simplify your path to secure CUI handling.

Comments are closed

5 Lessons Learned Supporting Organizations Through Level 2 CMMC Assessments

Key Takeaways

- Successful CMMC Level 2 assessments depend more on evidence maturity and operational consistency than on security tooling alone.

- Clearly defined shared responsibility between the customer, cloud provider, and service partners is critical to avoiding assessment risk.

- Incident response capabilities must be tested and supported by execution evidence, not just documented in a plan.

- Identity and access management controls receive significant scrutiny and require proof of ongoing enforcement.

- Organizations that standardize processes, governance, and control implementation are better positioned for smooth, defensible assessments.

As organizations across the Defense Industrial Base prepare for Cybersecurity Maturity Model Certification (CMMC) Level 2 assessments, many discover that achieving compliance is less about implementing new technologies and more about demonstrating that security practices are consistently executed, documented, and defensible.

Having supported organizations through numerous Level 2 assessments, we’ve observed recurring themes that separate successful assessments from difficult ones. While every environment is different, the same challenges tend to surface repeatedly once assessors begin reviewing evidence, interviewing personnel, and validating control implementation.

Here are five of the most important lessons we’ve learned along the way.

1. Level 2 Is Less About Tooling and More About Evidence Maturity

One of the most common misconceptions organizations bring into a Level 2 assessment is the belief that purchasing the right security tools automatically translates to compliance.

While technologies such as Microsoft Defender, Microsoft Sentinel, endpoint management platforms, and identity solutions are important components of a secure environment, they rarely become the primary obstacle during an assessment. Instead, organizations often struggle to produce clear, assessor-ready evidence that demonstrates how controls are implemented and maintained.

Assessors are not only looking for screenshots or configuration exports. They want to understand the complete story behind a control. That includes the policy that establishes the requirement, the technical implementation that enforces it, the procedures that support it, and the evidence that proves it is operating consistently over time.

In many environments, security processes exist but are not formally documented. Teams may be performing the right activities, but there is limited traceability between policies, technical controls, and operational execution. This creates friction during assessments and often results in lengthy evidence collection exercises.

We’ve found that organizations achieve better outcomes when evidence is treated as a deliverable rather than a byproduct. Standardized evidence templates, clear mappings between controls and artifacts, and centralized repositories make it significantly easier to demonstrate compliance. When policies, technical artifacts, and supporting narratives are linked together in a structured way, assessors can follow the evidence trail without requiring extensive clarification.

The lesson is simple: Strong security controls are important, but mature evidence management is often what determines how smoothly an assessment proceeds.

2. Shared Responsibility Confusion Creates Unnecessary Risk

Another recurring challenge involves shared responsibility.

Many organizations operate within cloud environments and rely on managed service providers, compliance partners, or other third parties to support portions of their security program. While these partnerships provide significant value, they can also introduce confusion about who is responsible for performing specific controls.

Questions around logging, monitoring, incident response, administrative management, and security operations frequently reveal gaps in understanding. Organizations often assume a provider is performing a function that remains their responsibility, while providers may assume the customer owns certain activities.

Assessors routinely probe these boundaries because they want to understand who is actually performing each control and how that responsibility is documented.

When ownership is unclear, organizations may struggle to explain operational processes consistently. Different stakeholders provide different answers, documentation becomes inconsistent, and confidence in the control implementation decreases.

The most successful organizations establish a formal Shared Responsibility Matrix that clearly defines ownership for every applicable control. Responsibilities should be mapped across the customer, cloud service provider, and supporting partners, then validated against actual operational practices.

Just as importantly, these responsibilities should align with the System Security Plan (SSP), supporting policies, procedures, and evidence artifacts. When ownership is documented and consistently reflected across assessment materials, organizations eliminate ambiguity and provide assessors with a clear understanding of how security functions are managed.

3. Incident Response Is Where Theory Often Breaks Down

Nearly every organization has an Incident Response (IR) plan.

Far fewer organizations can confidently demonstrate that the plan has been tested, validated, and executed in a realistic scenario.

During assessments, conversations about incident response often begin comfortably enough. Organizations can describe their documented procedures, escalation paths, and reporting requirements. However, confidence frequently declines when assessors begin asking questions about actual execution.

When was the last exercise conducted? What evidence exists from that exercise? How were lessons learned captured? How does the organization detect incidents and transition from detection to response?

These questions expose gaps that are difficult to identify through documentation reviews alone.

We’ve repeatedly seen organizations with strong IR policies but limited operational validation. Tabletop exercises have never been conducted. Roles and responsibilities remain unclear. Escalation timelines are not well understood. Detection tools operate independently from response workflows.

The organizations that perform best treat incident response as an operational capability rather than a compliance requirement.

Regular tabletop exercises, technical simulations, and structured runbooks help transform documented procedures into repeatable processes. More importantly, these activities generate evidence. Tickets, logs, timelines, after-action reports, and exercise records provide tangible proof that the organization can execute its response plan when needed.

Assessors want confidence that an organization can respond effectively to a real-world event. The ability to demonstrate tested processes and documented execution often carries significantly more weight than the existence of a well-written plan.

4. Identity and Access Controls Receive More Scrutiny Than Expected

Identity management consistently emerges as one of the most heavily scrutinized areas during Level 2 assessments.

Modern cybersecurity strategies increasingly rely on identity as the primary security perimeter, making access control practices particularly important. As a result, assessors spend significant time reviewing how organizations manage authentication, authorization, privileged access, and monitoring.

Common findings include inconsistent multi-factor authentication (MFA) enforcement, excessive privileged access, insufficient auditing, and limited visibility into administrative activity. In many cases, the required controls are technically implemented, but organizations struggle to prove that they are consistently enforced.

This distinction matters.

Assessors are not simply interested in whether a configuration exists today. They want evidence that demonstrates ongoing enforcement over time. Audit logs, sign-in records, privileged access histories, and monitoring reports help establish that controls are operating as intended.

Organizations that adopt standardized identity management practices tend to have fewer challenges during assessments. Consistent use of MFA, Conditional Access policies, Privileged Identity Management (PIM), device compliance controls, and centralized auditing creates a stronger foundation for both security and compliance.

Perhaps most importantly, these configurations should be supported by evidence that demonstrates historical enforcement. Being able to show not only the control itself, but also its continued operation, significantly strengthens an organization’s assessment posture.

5. Consistency Beats Perfection Every Time

The final lesson may be the most important.

Organizations often enter assessments believing they need a perfect environment. In reality, consistency is usually far more valuable than perfection.

Assessors understand that environments evolve. Technologies change, systems are updated, and organizations continue maturing their security programs. What assessors want to see is that controls are implemented consistently, governed appropriately, and managed through repeatable processes.

Inconsistent implementation creates far more concern than minor imperfections.

For example, an organization may have strong controls in one enclave while applying different standards elsewhere. Administrative procedures may vary between teams. Security configurations may differ across similar systems. Last-minute remediation efforts can introduce additional complexity and create uncertainty about whether controls are truly operational.

Consistency becomes even more important in cloud-centric environments where security capabilities may be distributed across cloud service providers, managed service providers, and the customer organization.

How a Phishing Attack Can Escalate Quickly

Author: Chris Bentkowski, Service Engineer at CloudFit

It only takes one click.

Despite significant advances in identity security, phishing remains one of the most effective attack methods because it targets people, not technology. Modern phishing campaigns are designed to steal more than just usernames and passwords. Increasingly, attackers are capturing legitimate multi-factor authentication (MFA) codes in real time, allowing them to bypass security controls that many organizations rely on.

What starts as a single phishing interaction can quickly escalate into a widespread security incident affecting multiple users, systems, and business operations.

Here’s how that escalation typically unfolds.

It Starts with a Convincing Login Page

Many phishing attacks begin with a user clicking a malicious link that redirects them to a fake login page designed to look identical to a trusted application.

Believing the page is legitimate, the user enters their username and password and, when prompted, provides a valid MFA code from their authentication application.

At that point, the attacker has everything they need to complete the authentication process and gain full access to the account, including the ability to establish control over authentication methods.

How the Attack Escalates

Once an attacker successfully signs in, the objective quickly shifts from accessing a single account to expanding throughout the environment.

Attackers commonly:

- Establish persistence to maintain long-term access.

- Expand access by compromising additional user accounts.

- Introduce unauthorized systems into the environment.

- Expose systems to the internet, increasing the risk of further compromise.

This demonstrates how a single compromised account can rapidly become a much broader organizational incident.

Internal Phishing and Lateral Movement

Once attackers gain control of a legitimate account, they often leverage the trust associated with that account to target others.

Common tactics include:

- Sending phishing emails to coworkers and external contacts.

- Sharing malicious files disguised as legitimate documents.

- Creating unauthorized access pathways, such as guest accounts or shared links.

Because these emails originate from a trusted internal account, recipients are far more likely to click links or open attachments. As a result, additional accounts can be compromised, allowing the attacker to continue moving throughout the organization.

How MFA Can Be Bypassed

Multi-factor authentication remains one of the most important security controls organizations can implement. However, attackers are increasingly designing phishing campaigns specifically to defeat it.

Rather than trying to crack MFA, attackers simply trick users into providing a legitimate authentication code on a malicious website.

When that happens, the attacker can:

- Complete the login process.

- Capture authentication session details.

- Potentially reconfigure or take control of MFA mechanisms.

This technique is commonly known as MFA phishing or token/session capture, where attackers use real-time user input to bypass authentication protections.

The Potential Impact

Once attackers establish access, the scope of the incident can grow quickly.

Organizations may be forced to:

- Reset multiple user accounts and MFA configurations.

- Remove unauthorized systems and access.

- Delete malicious emails and files.

- Investigate and remediate widespread malicious activity across the environment.

While incidents can often be contained with a timely response, recovering from a successful credential and MFA compromise can require significant effort across IT, security, and business teams.

How to Protect Yourself

Verify Before You Enter Credentials

- Only sign in through trusted, known URLs.

- Avoid logging in from links contained in unexpected emails or messages.

Never Enter MFA Codes on Untrusted Pages

- Your MFA code is just as sensitive as your password.

- If a login page or authentication prompt feels suspicious, stop immediately.

Watch for Common Red Flags

Be cautious of:

- Unexpected login prompts.

- Urgent requests to “verify your account.”

- Unfamiliar file-sharing notifications.

- Emails that create unnecessary urgency or pressure.

Report Suspicious Activity Immediately

If something doesn’t seem right:

- Report phishing attempts using your organization’s reporting process.

- If you believe you’ve entered credentials on a malicious site, notify your IT or security team immediately.

The sooner an incident is reported, the faster it can be contained.

Key Takeaway

If an attacker captures both your password and your MFA code, they can gain full access to your account.

Today’s phishing attacks are designed to deceive users in real time, making them far more sophisticated than traditional email scams. Staying vigilant, verifying login pages before entering credentials, and reporting suspicious activity immediately can prevent a single phishing attempt from becoming a much larger security incident.

Comments are closed