blog

What Are the CIS Controls? A Practical Guide to Building a Stronger Security Program

acrooks@teamascend.com (Aubrey Crooks) — Thu, 16 Jul 2026 14:23:01 GMT

Cybersecurity can quickly become a tool conversation.

Endpoint protection. Email security. MFA. Backups. Logging. Vulnerability scanning. Pen testing. Every piece matters, but tools alone do not tell an organization whether its security program is actually mature, measurable, or improving.

That is where the Center for Internet Security Controls, or CIS Controls, are useful.

The CIS Controls give organizations a practical framework for understanding what good security should look like, how to prioritize improvements, and how to measure progress over time. For small and mid-sized businesses, they can also make cybersecurity easier to talk about because they shift the conversation away from isolated products and toward business risk, operational maturity, and defensible progress.

What Are the CIS Controls?

The CIS Controls are a set of cybersecurity best practices created by the Center for Internet Security to help organizations protect their systems, data, users, and networks from common threats.

They are designed to be practical. Instead of starting with abstract security concepts, the CIS Controls focus on the real safeguards organizations need in place, such as knowing what devices are connected to the environment, managing user access, protecting email and web activity, reviewing security logs, recovering data, and responding to incidents.

That practicality is what makes the CIS Controls useful for businesses that need a clearer way to understand cybersecurity. They give teams a shared structure for asking important questions:

Do we know what assets and software are in our environment?
Are accounts and permissions being managed properly?
Are systems configured securely?
Are we protecting users from common attack paths?
Are logs being collected and reviewed?
Do we have a process for responding when something goes wrong?
Are we testing whether our defenses actually work?

The CIS Controls do not replace security tools, policies, or technical expertise. Instead, they help organize those pieces into a more complete security program. For organizations that are not sure where to start, they provide a practical foundation. For organizations that already have security tools in place, they create a way to evaluate whether those tools are supporting the right outcomes.

Why the CIS Controls Matter

The CIS Controls matter because they give organizations a practical way to prioritize cybersecurity.

Without a framework, security decisions can become reactive. A business may add a tool after a phishing incident, update a policy after an audit request, or review backups only after something goes wrong. Each action may be useful, but without a larger structure, it can be hard to know whether the organization is actually becoming more secure or, in some cases, less.

The CIS Controls help create that structure.

They give businesses a way to look at cybersecurity as a connected program instead of a collection of separate tasks. Asset inventory, access control, malware defense, logging, recovery, incident response, and penetration testing all support different parts of the same goal: reducing risk in a way that can be understood, measured, and improved.

That is especially important for small and mid-sized businesses. Many organizations know they need stronger cybersecurity, but they do not always know what should come first. The CIS Controls help answer that question by giving teams a clearer path forward. They can identify what is already in place, what is missing, and which improvements will make the biggest difference.

In that way, the CIS Controls function as more than a best-practice list. They can become a roadmap. They help organizations move from basic cyber hygiene toward a more mature security program, one step at a time.

The value is not just knowing what security should include. The value is having a practical way to decide what to do next.

The 18 CIS Controls at a High Level

What Are CIS Implementation Groups?

The CIS Controls are not meant to be applied the same way for every organization. A small business with limited internal IT resources will not have the same security needs, budget, or staffing as a larger organization with a dedicated security team.

That is why the CIS Controls are divided into Implementation Groups.

Implementation Groups help organizations prioritize which safeguards to focus on based on their current risk, resources, and security maturity. Instead of expecting every business to implement every safeguard at once, CIS creates a more practical path for building security over time.

IG1: Essential Cyber Hygiene

Implementation Group 1, or IG1, is the starting point. It focuses on foundational safeguards that help protect against common attacks and establish basic cyber hygiene.

For many small and mid-sized businesses, IG1 is the most realistic place to begin. It helps answer the question: What should we have in place first?

IG2: Building on the Foundation

Implementation Group 2 builds on IG1. It is typically a better fit for organizations with more complex environments, greater risk exposure, or more resources available for cybersecurity.

At this stage, the organization is not just trying to establish the basics. It is working toward stronger processes, better visibility, and more consistent security operations.

IG3: Advanced Security Maturity

Implementation Group 3 includes the most advanced safeguards. It is generally intended for organizations with higher risk, more mature security programs, or dedicated internal security expertise.

These organizations may need deeper monitoring, stronger governance, more formalized response processes, and greater validation of their security controls.

The important thing to understand is that Implementation Groups are not a pass-or-fail model. They are a way to make the CIS Controls more usable. They help organizations start where they are, focus on what matters most, and build toward a stronger security program over time.

How CIS Connects Security Tools, Processes, and Evidence

Security tools are important, but they are only part of a strong security program.

A business may have endpoint protection, email filtering, multifactor authentication, backups, logging, and other safeguards in place. Those tools can all support better security, but the bigger question is whether they are being used in a way that is consistent, measurable, and connected to the organization’s actual risk.

The CIS Controls help create that connection.

Instead of looking at each tool in isolation, the CIS Controls help organizations understand what each safeguard is meant to accomplish. Endpoint protection may support malware defense. Email security may support protection against phishing and malicious links. Logging may support investigation and response. Backups may support recovery. Penetration testing may help validate whether controls are working as expected.

The framework also brings process and evidence into the conversation. It is not enough to have a tool turned on. Organizations also need to understand how it is managed, how often it is reviewed, who is responsible for it, and what evidence exists to show that the safeguard is actually working.

That is where CIS becomes especially useful. It gives businesses a way to connect the technical side of cybersecurity with the operational side. Tools, policies, documentation, review cycles, response procedures, and reporting all become part of the same larger picture.

For business leaders, that makes cybersecurity easier to understand. For technical teams, it creates a clearer way to prioritize work. And for organizations trying to improve over time, it provides a structure for showing progress with more than assumptions or good intentions.

How to Get Started With the CIS Controls

Getting started with the CIS Controls does not mean trying to implement every safeguard at once. For most organizations, the better approach is to understand where the business stands today, identify the most important gaps, and create a realistic path forward.

A good starting point is to determine which Implementation Group best fits the organization. Many small and mid-sized businesses begin with IG1 because it focuses on essential cyber hygiene. From there, the organization can evaluate which safeguards are already in place, which ones are partially in place, and which ones need more attention.

This is where documentation and evidence matter. It is one thing to believe a process exists. It is another to show how that process works, who owns it, how often it happens, and whether it is being followed consistently. That does not mean every organization needs a complex compliance program, but it does mean cybersecurity should be based on more than assumptions.

For many businesses, a CIS Controls Assessment can help create that baseline. It gives the organization a clearer view of its current security posture and helps turn the CIS Controls into a prioritized list of next steps.

From there, the work becomes more manageable. The business can focus on the safeguards that matter most, assign ownership, make improvements over time, and revisit the framework as the environment changes.

The goal is not to finish cybersecurity. The goal is to build a security program that can keep improving.

How DotStar Uses CIS as a Security Framework

DotStar uses the CIS Controls as a practical framework for helping organizations understand, measure, and improve their security programs.

That matters because cybersecurity can easily become fragmented. One tool may protect endpoints. Another may filter email. Another may collect logs. Another may support backups or recovery. Each piece has value, but without a framework, it can be difficult to understand how those pieces work together or where the biggest gaps still exist.

CIS gives that work structure.

For DotStar, the CIS Controls help connect assessment, reporting, managed protection, detection and response, advisory support, and recurring validation into one larger security picture. The goal is not simply to deploy security tools. The goal is to help organizations understand where they are, what needs attention, and how each improvement supports a stronger security program.

This also makes CIS useful as a roadmap. An organization may start by identifying its current gaps, then focus on foundational safeguards, improve operational visibility, strengthen response processes, and validate progress over time. Each step becomes easier to prioritize because it connects back to a recognized framework.

For businesses and MSP partners, that creates a clearer way to talk about cybersecurity. Instead of relying on disconnected reports or one-off recommendations, CIS helps turn security into an ongoing process that can be measured, explained, and improved.

For continued CIS monitoring and support, learn more about CIS Compliance.

The Real Value of the CIS Controls

The CIS Controls give organizations a practical way to understand cybersecurity, prioritize improvements, and measure progress over time.

They are useful because they bring structure to a topic that can otherwise feel overwhelming. Instead of looking at cybersecurity as a long list of tools, tasks, and technical decisions, the CIS Controls help organizations see how those pieces fit together into a stronger security program.

For some businesses, that starts with basic cyber hygiene. For others, it means improving visibility, strengthening processes, validating existing controls, or preparing for more formal compliance needs. The right path depends on the organization’s size, risk, resources, and current maturity.

What matters most is having a clear framework to guide the work.

Cybersecurity is not something an organization finishes once. It is something that has to be maintained, reviewed, and improved as the business changes. The CIS Controls give organizations a practical foundation for doing that work with more clarity and confidence.

Threat Hunting for PowerShell Activity: Lessons from Powercat

sgrinsell@securedotstar.com (Sean Grinsell) — Thu, 16 Jul 2026 14:21:49 GMT

Some security concerns are easy to recognize. A known malware file, a suspicious login, or a blocked phishing attempt gives security teams a clear signal that something needs attention.

Other situations are less obvious.

Powercat falls into that second category. It is not automatically malicious, but it can become concerning when it appears in the wrong context. Because it is based on PowerShell, it also sits within a larger challenge many organizations face: understanding when legitimate administrative tools are being used in unexpected ways.

That distinction matters. Modern security teams cannot rely only on whether a tool is "good" or "bad." They also need to understand how it is used, who uses it, and whether the activity fits the environment.

What is Powercat

Powercat is a PowerShell-based utility inspired by Netcat-style functionality. At a high level, it can support network-style communication and remote interaction through PowerShell.

In legitimate settings, PowerShell-based tools may be used for approved testing, troubleshooting, or administrative work. In other situations, similar activity may raise questions about whether someone is trying to establish an unauthorized connection, interact with a system remotely, move files, or prepare for additional activity.

The key point is that Powercat should not be treated as automatically malicious. Its risk depends on context.

A tool that makes sense during approved testing may be unusual if it appears on an endpoint where it has no clear business purpose. Activity that appears normal to an administrator may be suspicious if it is tied to an unexpected user, system, or communication pattern.

That is why Powercat is worth discussing: not because every organization needs to obsess over one specific utility, but because it represents a broader security challenge. Businesses need a way to recognize when powerful, legitimate tools are being used in ways that do not match normal operations.

Threat Hunting for Powercat: Why PowerShell Activity Matters

PowerShell is a normal part of many Windows environments. Administrators use it to automate tasks, manage systems, troubleshoot issues, and support day-to-day IT operations. That is exactly what makes it powerful, but that's also what makes it worth monitoring.

When security teams look at Powercat-related activity, they are rarely looking at the tool in isolation. They are looking at the surrounding behavior. A single PowerShell command may not tell the full story, but the context around that command can reveal whether the activity fits normal operations or deserves closer investigation.

For example, your security team may want to understand whether PowerShell was launched by an expected user, from an expected device, during an expected type of administrative activity. They may also look at whether the activity involved unusual command-line patterns, unexpected script execution, abnormal system-to-system communication, or file movement that does not align with normal business behavior.

This is where threat hunting becomes valuable. Traditional security alerts are important, but they are not the whole picture. Alerts are typically built around known signals: a detection rule, a suspicious pattern, or a defined behavior that a tool has been configured to recognize. Threat hunting takes a more investigative approach. It asks, "What activity could be happening in the environment that may not have generated a clear alert yet?"

With Powercat, that mindset matters because the concern is not simply whether a specific utility appears. The concern is whether PowerShell is being used in a way that creates risk.

A mature hunt does not stop at "Powercat was seen" or "PowerShell was used." It looks for relationships between users, devices, commands, connections, and business context. It separates expected administrative behavior from activity that may indicate unauthorized access, remote interaction, file movement, or preparation for additional action.

That level of visibility is what helps security teams move from reactive alert review to proactive validation. Instead of waiting for a single tool to declare something malicious, threat hunting helps teams ask better questions, confirm what is happening, and improve detection logic over time.

What This Means for Your Security Program

Powercat is a useful example, but the larger lesson is not limited to one tool. The real question is whether your organization can see and understand how administrative utilities are being used across your environment. Many businesses have security tools in place, but tool ownership alone does not guarantee meaningful visibility. A security program needs to connect data, context, investigation, and response. That starts with knowing what normal looks like.

If your team does not have a baseline for expected PowerShell usage, it becomes harder to recognize when something is unusual. If command-line activity is not visible across endpoints, suspicious behavior may be missed. If alerts are not tied to a clear investigation process, even strong detections can lose value. If findings are not reviewed and refined over time, the same blind spots can remain in place.

A stronger security program does not need to treat every PowerShell event as an emergency. It needs a practical way to answer the right questions:

Can we see what happened?
Do we understand whether it was expected?
Can we investigate it quickly?
Do we have a process for escalating suspicious activity?
Are we using what we learn to improve monitoring and response?

That is the difference between passive security monitoring and active security operations.

Powercat-related hunting is one example of how organizations can mature their approach. The goal is not to chase every possible tool an attacker might use. The goal is to build the visibility, process, and response discipline needed to recognize when legitimate tools are being used in suspicious ways.

When that foundation is in place, security becomes more than a collection of alerts. It becomes an ongoing cycle of validation, learning, and improvement.

How DotStar Helps

Powercat is one example of a larger security challenge: knowing when legitimate tools are being used in suspicious ways.

DotStar helps organizations and MSP partners move beyond passive monitoring by turning security data into visibility, context, and action. Our managed security services support endpoint monitoring, threat hunting, detection refinement, reporting, and response workflows so your team can better understand what happened, why it matters, and what to do next.

The goal is not just to generate more alerts. It is to help you build a stronger security program over time.

Frequently Asked Questions

What is threat hunting?

Threat hunting is the proactive process of looking for signs of suspicious activity before a standard alert confirms a problem. Instead of waiting for a tool to flag something, your security team searches for behaviors, patterns, and context that may point to risk.

Is Powercat malware?

Powercat is not automatically malware. It is a PowerShell-based utility that can have legitimate administrative, testing, or troubleshooting uses. The risk depends on context. If Powercat appears unexpectedly, is used by an unusual account, runs from an unfamiliar system, or is tied to suspicious network activity, your security team should investigate further.

Why do Attackers use PowerShell?

Attackers often favor tools that already exist in an environment.PowerShell is built into Windows, widely used by IT teams, and powerful enough to support many administrative tasks. That makes PowerShell useful for legitimate work, but it also means suspicious activity can sometimes blend into normal operations. This is why visibility into PowerShell usage is an important part of threat hunting and endpoint monitoring.

What should businesses monitor PowerShell for?

Businesses should monitor for PowerShell activity that does not match normal administrative behavior. That may include unusual command-line patterns, unexpected script execution, unfamiliar users running PowerShell, abnormal system-to-system communication, or file movement that does not align with business operations.

The goal is not to treat every PowerShell event as malicious. The goal is to understand what normal looks like so your security team can recognize when activity deserves a closer look.

Can security tools detect suspicious Powercat activity automatically?

Some security tools may detect known suspicious patterns tied to Powercat or PowerShell activity. However, automatic detection is only one part of the picture.

Powercat-related activity often requires context. Your security team needs to understand who ran the command, where it ran, what systems were involved, and whether the activity matches expected business use. Strong detection works best when it is paired with investigation, tuning, and a clear response process.

Threat Hunting for Disabled System Restore: Why Endpoint Recovery Matters

sgrinsell@securedotstar.com (Sean Grinsell) — Thu, 16 Jul 2026 14:21:48 GMT

Some attacker behaviors are designed to gain access. Others are designed to make recovery harder.

That second category is easy to overlook. When recovery features are changed or disabled, the activity may not look as urgent as malware execution, suspicious login activity, or a blocked phishing attempt. But it can still matter because recovery options help determine how quickly your team can respond when something goes wrong.

System Restore is one example. It's not a complete backup strategy, and it should not be treated as the only way to recover from an incident. But when recovery-related features are unexpectedly disabled, it raises an important security question: was this part of normal system administration, or did something weaken the endpoint’s ability to recover?

That distinction matters. Modern security programs need visibility into more than active threats. They also need visibility into changes that affect resilience, recovery, and response.

What is System Restore?

System Restore is a Windows recovery feature that can help roll back certain system files, settings, and configurations to a previous state. It is designed to support recovery from some types of system issues, such as problematic updates, configuration changes, or software-related problems.

It is not the same as a full backup. System Restore does not replace a backup and recovery plan, and it does not protect every type of data or business-critical system. That said, it can still be relevant from a security perspective.

If System Restore is disabled as part of an approved IT process, that may be expected. If it is disabled unexpectedly, especially across multiple systems or alongside other suspicious behavior, your security team may need to take a closer look.

A setting change that makes sense during system provisioning, policy enforcement, or endpoint management may be normal. The same change may be more concerning if it happens without a clear business reason, appears on an unusual endpoint, or occurs near other activity that suggests malware, ransomware preparation or unauthorized system control.

That is why this topic is worth discussing: not because System Restore is the center of endpoint recovery, but because recovery-related changes can reveal whether your organization has the visibility needed to understand when resilience is being weakened.

Threat Hunting for Disabled System Restore: Why Recovery Visibility Matters

Threat hunting is not only about looking for active malware. It is also about asking better questions about the environment before a standard alert tells you there is a problem. Disabled System Restore is a good example of that mindset.

When your security team reviews recovery-related changes, they are rarely looking at one setting in isolation. They are looking at the surrounding context. Who made the change? Which device was affected? Was the change expected? Did it happen during a normal administrative process? Were other security or recovery controls changed around the same time?

That context matters because attackers may try to limit recovery options during certain types of activity. If a system is compromised, anything that reduces the ability to roll back, recover, or investigate can create more pressure on the business.

For example, your security team may want to understand whether System Restore was disabled by an expected administrative process, whether similar changes appeared across multiple endpoints, whether the change aligned with normal endpoint management activity, or whether it appeared alongside suspicious process activity, unusual scripts, or signs of unauthorized access.

This is where threat hunting becomes valuable.

A standard alert may focus on a known malicious file, a blocked behavior, or a specific detection rule. A threat hunt can take a broader view. It asks, “Are there signs that important recovery or security settings changed in a way that does not match normal operations?”

With disabled System Restore, the concern is not simply whether the feature is on or off. The concern is whether recovery-related changes make sense for the environment.

A mature hunt looks for relationships between devices, users, system changes, administrative activity, and business context. It helps separate expected IT management from activity that may weaken resilience or prepare the environment for a more damaging event.

That level of visibility helps security teams move from reactive alert review to proactive validation. Instead of waiting until recovery is needed, threat hunting helps your team confirm whether recovery-related controls are being changed in expected ways and whether those changes should prompt further investigation.

What This Means for Your Security Program

Disabled System Restore is a useful example, but the larger lesson is not limited to one Windows feature. The real question is whether your organization can see and understand changes that affect endpoint recovery, system resilience, and response readiness. Many businesses think about recovery only after an incident. A stronger security program treats recovery visibility as part of ongoing security operations.

That starts with knowing what normal looks like. If your team does not know when recovery settings are expected to change, it becomes harder to recognize when a change is unusual. If endpoint configuration changes are not visible, important signals may be missed. If security findings are not connected to an investigation process, even meaningful alerts can lose value. If recovery readiness is not reviewed over time, gaps may remain hidden until they matter most.

A stronger security program does not need to treat every disabled recovery feature as an emergency. It needs a practical way to answer the right questions:

Can we see when recovery-related settings change?
Do we know whether the change was expected?
Can we connect the change to a user, device, or administrative process?
Can we identify whether similar changes happened across multiple endpoints?
Do we have a process for investigating activity that could weaken recovery?
Are we using what we learn to improve monitoring and response?

That is the difference between passive security monitoring and active security operations.

Threat hunting for disabled System Restore is one example of how organizations can mature their approach. The goal is not to rely on one recovery feature or chase every configuration change. The goal is to build the visibility, process, and response discipline needed to recognize when normal system settings are being changed in ways that could increase risk.

When that foundation is in place, security becomes more than a collection of alerts. It becomes an ongoing cycle of validation, learning, and improvement.

How DotStar Helps

Disabled System Restore is one example of a larger security challenge: knowing when endpoint changes may weaken recovery, resilience, or response.

DotStar helps organizations and MSP partners move beyond passive monitoring by turning security data into visibility, context, and action. Our managed security services support endpoint monitoring, threat hunting, detection refinement, reporting, and response workflows so your team can better understand what changed, why it matters, and what to do next.

The goal is not just to generate more alerts. It is to help you build a stronger security program over time.

Frequently Asked Questions

What is System Restore?

System Restore is a Windows recovery feature that can help roll back certain system files, settings, and configurations to a previous state. It may help recover from some system issues, but it is not a replacement for a full backup and recovery strategy.

Why would an attacker disable System Restore?

An attacker may try to disable recovery features to make it harder to restore a system after malicious activity. This can be especially concerning when the change appears alongside other suspicious behavior, such as unusual scripts, unauthorized access, or signs of malware activity.

Is a disabled System Restore always suspicious?

No. System Restore may be disabled for legitimate administrative reasons, endpoint management policies, or system configuration standards. The risk depends on context. Your security team should understand who made the change, where it happened, why it happened, and whether it fits normal operations.

Is System Restore the same as a backup?

No. System Restore is not the same as a backup. It can help roll back certain system changes, but it does not replace a complete backup and recovery plan for business-critical data, systems, or applications.

What should businesses monitor for?

Businesses should monitor for recovery-related changes that do not match normal administrative behavior. That may include unexpected changes to System Restore, unusual endpoint configuration changes, suspicious script activity, or similar changes across multiple systems.

The goal is not to treat every change as malicious. The goal is to understand what normal looks like so your security team can recognize when activity deserves a closer look.

How does threat hunting support recovery readiness?

Threat hunting helps your team proactively look for signs that recovery or security settings have changed in unexpected ways. That visibility can help validate whether your environment is operating as expected, identify gaps before an incident, and improve monitoring over time.