Skip to main content

NIST CSF 2.0 – Protect Function Deep Dive: Platform Security (PR.PS)


Most organizations don’t get breached because they chose the wrong cloud provider, operating system, or endpoint platform.

They get breached because those platforms were not securely configured, maintained, or governed over time.

Platform Security (PR.PS) exists because attackers don’t usually defeat technology—they exploit neglect:

  • Unpatched systems

  • Misconfigurations

  • Unsupported platforms

  • Inconsistent security baselines

PR.PS is where cybersecurity discipline shows up every day, long after the architecture diagrams are finished.

How PR.PS Fits Into the Protect Function

So far in the Protect function:

  • PR.AA answered who can access systems

  • PR.AT addressed how people behave

  • PR.DS focused on what data is truly at risk

PR.PS answers the next critical question:

Are the platforms we depend on actually secure by design and by default?

“Platforms” include:

  • Servers (on-prem and cloud)

  • Endpoints

  • Operating systems

  • Containers

  • Virtual machines

  • Cloud services

  • Core infrastructure components

If it runs workloads or supports business operations, PR.PS applies.

Beginner Callout: What “Platform Security” Really Means

Platform security is not a single tool or product.

It means:

  • Systems are hardened before use

  • Secure configurations are consistent

  • Vulnerabilities are addressed predictably

  • Unsupported technology is minimized

  • Drift is detected and corrected

Think of platforms like vehicles:

  • Buying a safe car matters

  • Maintaining it over time matters more

Why Platform Security Matters to Executives

From an executive and board perspective, platform security directly impacts:

  • Breach likelihood

  • Ransomware exposure

  • Operational resilience

  • Regulatory findings

  • Cyber insurance outcomes

Many high-impact incidents start with something simple:

  • A missed patch

  • A default setting

  • An outdated system still “temporarily” in use

PR.PS is about preventing avoidable failures, not chasing advanced threats.

Common PR.PS Failures (Even in Mature Organizations)

1. Inconsistent Baselines

When platforms are:

  • Built differently across teams

  • Patched on different schedules

  • Configured inconsistently

Security becomes unpredictable and difficult to defend.

2. Patch Management Without Prioritization

Trying to patch everything immediately usually means:

  • Teams get overwhelmed

  • Critical systems wait

  • Risk is poorly managed

PR.PS is about risk-based prioritization, not panic.

3. Allowing “Temporary” Exceptions to Become Permanent

Unsupported operating systems
Legacy applications
Special configurations

These often stay far longer than planned—and quietly accumulate risk.

How to Implement PR.PS in a Practical, Understandable Way

1. Define What “Secure by Default” Means for Your Organization

At minimum, organizations should define:

  • Approved platforms

  • Required security configurations

  • Baseline hardening standards

  • Minimum patch levels

This turns security from a judgment call into a repeatable process.

2. Standardize Platform Builds Wherever Possible

Standard images and configurations:

  • Reduce errors

  • Speed deployment

  • Simplify monitoring

  • Improve incident response

Customization should be the exception—not the norm.

3. Treat Vulnerability Management as a Business Process

Effective PR.PS programs:

  • Prioritize vulnerabilities based on impact and exposure

  • Consider asset criticality

  • Track remediation timelines

  • Escalate risk-based exceptions

Patching without context wastes effort.
Context without action increases risk.

4. Address Platform Drift Continuously

Over time, platforms change:

  • Configurations drift

  • Security settings are altered

  • Controls are disabled to “fix” problems

PR.PS maturity includes:

  • Configuration monitoring

  • Drift detection

  • Automated remediation where possible

5. Reduce Dependency on Unsupported Platforms

Unsupported platforms:

  • Don’t receive security updates

  • Increase operational fragility

  • Raise audit and regulatory risk

Every unsupported system should have:

  • A documented owner

  • An approved exception

  • A retirement or remediation plan

Real-World Executive Example

Two organizations are hit with the same ransomware campaign.

  • Organization A had standardized builds, timely patching, and restricted admin access → limited spread

  • Organization B had inconsistent platforms, legacy systems, and broad privileges → full environment impact

Same threat.
Different outcomes.

That difference is PR.PS maturity.

Metrics That Make Platform Security Visible

Foundational Metrics

  • % of platforms meeting baseline standards

  • % of systems on supported software versions

  • Patch compliance rates by severity

  • Number of unauthorized configurations detected

These demonstrate operational control.

Risk-Focused Metrics

  • Exposure time for critical vulnerabilities

  • High-risk platforms with approved exceptions

  • Repeated configuration drift events

  • Platform-related incident root causes

These show whether risk is being reduced over time.

CISO Takeaways

For new and aspiring CISOs:

  • Most attacks exploit known weaknesses

  • Platform hygiene prevents entire classes of incidents

  • Consistency matters more than perfection

  • Legacy risk always becomes leadership risk

PR.PS is not glamorous—but it is foundational.

When platform security is strong:

  • Incident response is easier

  • Impact is reduced

  • Confidence increases at the executive level

What “Good” Looks Like

A strong PR.PS capability means:

  • Platforms are built securely from the start

  • Vulnerabilities are prioritized realistically

  • Unsupported systems are tracked and managed

  • Configuration drift is detected early

  • Security expectations are clear and enforceable

For beginners, this creates clarity.
For executives, it creates trust.
For CISOs, it creates resilience.

Final Thoughts

Advanced attackers get headlines—but basic failures cause most damage.

PR.PS exists to ensure:

  • The fundamentals are done well

  • Known risks are addressed consistently

  • Technology supports resilience instead of undermining it

Identity controls decide who gets in.
Awareness shapes human behavior.
Data security defines impact.

Platform security determines whether systems fail quietly—or catastrophically.

Labels:

Comments

Post a Comment

Popular posts from this blog

Asset Management - Physical Devices - What do you have? Do you know?

Asset management and inventorying your physical systems, we all know we should do it, and I am sure most try.  I am not going to talk about the should have, would have or could have. Instead, I am going to focus on the risks associated with the NIST CSF control ID-AM.1.   The control simply states, “Physical devices and systems within the organization are inventoried.”  At the simplest level, this control is saying that the organization inventories all physical systems that are apart of the information system. In my opinion, the control is foundational because how can you secure something if you don't know it exists.  If you are not inventorying your systems, how do you know if they have adequate controls to protect the data and network.   If you had a breach of data, would you know what type of data was involved, or would you even know if you had a breach?  To further extend this, how can you perform a risk assessment on the system to understand and relay ...
Post a Comment
Read more

Vulnerability Management… It’s easy - Planning

I am sure you have had either consultants, vendors, or heard at a conference that vulnerability management is foundational security control.  While I agree that it is an essential control, I also understand that it is challenging to implement.  Vulnerability management is not just to pick a tool, scan, and fix issues.  Many components make it a complicated journey.  This series will attempt to help break it down and give you ideas on how this complex service and be delivered effectively.    Planning   Objective When you start, I recommend creating a targeted objective and set of measures against your objective.   Ensure that you keep in mind your organization’s culture, politics, and risk appetite as you are developing your objective.   I have seen some target just “critical” systems for regulatory compliance, whereas others have targeted their entire enterprise.   No matter your scope, keep in mind your team’s current resource...
Post a Comment
Read more

The Detect Function in NIST CSF 2.0: The Risk of Seeing Too Late—or Too Much

In NIST Cybersecurity Framework 2.0 (CSF 2.0) , the Detect function represents the organization’s ability to identify the occurrence of a cybersecurity event in a timely and reliable manner . While Protect focuses on reducing the likelihood of compromise, Detect determines how quickly and how accurately an organization recognizes that something has gone wrong. For CISOs and security leaders, detection is where many programs quietly fail. Not due to a lack of tools, but due to poor signal quality, unclear objectives, and misalignment with business impact. Detection that is late, noisy, or misunderstood can be as damaging as no detection at all. Official NIST CSF 2.0 guidance is available here: https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20 What the Detect Function Is (and What It Enables) Under CSF 2.0, the Detect (DE) function focuses on outcomes related to: Continuous monitoring Anomalies and event detection Security logging and analysis Threat intelligence ...
Post a Comment
Read more