Post Syndicated from Michael Chroney original https://www.rapid7.com/blog/post/pt-cyber-grc-available-prove-compliance-security

Compliance has become one of the biggest operational drains on modern security teams. CISOs are being asked to manage a growing sprawl of frameworks, prove control effectiveness more often, respond to more customer assurance requests, track risk across a growing web of third parties, and give executives and the board a clearer answer on whether cyber risk is actually going down.

Most of that pressure does not come from the frameworks themselves. It comes from the way compliance is still handled in many organizations, with security work happening in one set of tools and governance, risk, and compliance workflows managed somewhere else. Security teams detect exposures, investigate threats, validate risk, and drive remediation in active systems. Governance, Risk and Compliance (GRC) teams are often left managing controls, evidence, audits, third-party risk, and reporting in separate systems of record, which turns compliance into a constant reconciliation exercise rather than an extension of the security program.

That separation creates real drag. Skilled technical teams get pulled into repeated cycles of screenshots, exports, control validation, and spreadsheet updates, while CISOs are still left trying to answer the question that matters most: are our controls actually working right now?

Available today, Rapid7 Cyber GRC completely changes that model by connecting governance, risk, and compliance workflows to the security data and activity already happening across the environment. The result is a more connected way to reduce manual work, improve readiness, and turn security action into compliance proof.

Why compliance needs to move at the speed of security

For years, compliance work followed a familiar rhythm: prepare for the audit, gather evidence, prove the control, respond to findings, and start over when the next framework, customer review, or regulatory requirement arrives.

That rhythm works in conflict with how security teams operate today. Modern environments change continuously. Assets appear, cloud configurations drift, access permissions change, vulnerabilities emerge, vendors introduce risk, and remediation work is always in motion.

This leaves a widening gap between the state of the environment and the state of the evidence. A control that looked effective during the last audit may drift weeks later. A remediation effort may reduce risk, but the compliance record may not reflect it. A new exposure may change the risk tied to a control before the next review begins.

Boards and customers are asking for something more credible than periodic audit readiness. They want to understand whether security work is actually improving control health and reducing risk over time. 

That is the shift from audit prep to continuous cyber assurance, built on better context and closer alignment between teams. As Bill Theissen, Managing Partner and VP of Consulting Services at Cyber Watch Systems, put it, “What excites me most about Rapid7 Cyber GRC is its ability to use existing security data, asset inventories, and API connectivity to produce more accurate, timely, and defensible risk reporting. Just as important, it helps bridge security engineering and GRC teams through a shared view of risk and a common language for communicating it.”

Cyber GRC is designed to support that shift by making governance, risk, and compliance part of how security teams prioritize, act, and prove progress. Compliance should not only document security activity after the fact – it should help show how that activity makes the business safer.

How Cyber GRC connects action to proof

Rapid7 Cyber GRC brings core GRC workflows into one place, including compliance program management, control monitoring, evidence collection, policy management, audit preparation, risk management, third-party risk management, exceptions, and reporting. Instead of managing those workflows in separate tools, teams can connect them to security context from the environment they are actively protecting.

Cyber GRC helps teams operationalize that model in a few practical ways:

• Control monitoring helps teams see where requirements are being met and where gaps need attention. 

• Evidence workflows help teams collect, organize, and reuse proof across frameworks instead of rebuilding it for every audit. 

• Policy management helps link policies to controls, so teams can understand how documentation supports readiness. 

• Risk and issue workflows help teams assign ownership, track remediation, and prioritize work based on business and security context.

The value of that model is not just administrative efficiency. Security teams need confidence that controls are operating as intended, not simply that a control exists on paper. A policy may be in place without the control performing effectively. A remediation ticket may be closed without the underlying risk truly being reduced. Control testing and monitoring help close that gap by showing whether controls are functioning as expected, while issue and remediation workflows connect those findings to owners and next steps.

By connecting controls, evidence, risk, issues, policies, and remediation activity, Cyber GRC gives SecOps, IT, GRC, and compliance teams a shared view of where they stand and what needs to happen next.

Why third-party risk needs to be part of the same workflow

Third-party risk has become too significant to sit outside the rest of the security and compliance program. As organizations rely on more outside services, software, and vendors, they need a way to connect vendor risk to the same controls, evidence, remediation, and reporting workflows used internally. Verizon’s 2026 DBIR found that breaches involving third parties increased 60% from the previous year’s dataset and accounted for 48% of total breaches, which makes that connection harder to treat as optional.

Cyber GRC brings third-party risk management into the same operating picture by combining vendor oversight, control tracking, issue management, and evidence workflows in one place. That gives teams a more coherent way to assess external dependencies, understand where vendor risk affects control posture, and track action without creating yet another disconnected program.

Give leadership a better risk story

CISOs are under pressure to show progress in a way executives and boards can understand, and audit status alone does not tell the whole story.

Cyber GRC helps teams connect day-to-day security and compliance activity to higher-level reporting, including control health, readiness status, open risks, remediation progress, third-party dependencies, and evidence coverage. That gives leaders a clearer view of which gaps matter most, what is being done about them, and how security work is reducing risk.
What makes that more useful is the quality of the underlying context. When controls, evidence, vulnerabilities, risk, and remediation are tied together, leadership gets a stronger basis for understanding not just whether the organization is compliant, but whether its controls are keeping pace with the way risk is actually developing.

Why Rapid7

Security leaders have an opportunity to make compliance more connected, more useful, and closely aligned to the work already happening across their security program.

Rapid7 approaches Cyber GRC as part of a broader security program. What makes that more useful is the quality of the underlying context. When controls, evidence, vulnerabilities, risk, and remediation are tied together, leadership gets a stronger basis for understanding not just whether the organization is compliant, but whether its controls are keeping pace with the way risk is actually developing.

That connection is at the core of what makes this solution different. Compliance proof is stronger when it is grounded in security context, not assembled after the fact from disconnected tools and static reports. With Rapid7 Cyber GRC, teams can move from documenting compliance activity to showing how security work is improving control health and reducing risk in real time.

See how Rapid7 Cyber GRC can help your team turn security operations into continuous cyber assurance.

Post Syndicated from Mahak Arora original https://aws.amazon.com/blogs/compute/introducing-modularized-kernel-cryptography-in-amazon-linux/

We are introducing modularized kernel cryptography in Amazon Linux 2023, an approach that separates Federal Information Processing Standard (FIPS) 140-3 cryptographic components into an independent kernel module that can be certified once and reused across subsequent kernel versions. In this post, we describe how this modular approach works, what it means for FIPS compliance workflows, and how customers can prepare for adoption.

Previously, when any part of the kernel changed, the entire kernel binary had to go through FIPS re-certification because the cryptographic code was embedded within it. With this modular approach, only the standalone cryptographic module undergoes validation, which means non-cryptographic kernel changes no longer require full re-certification. This can help customers who need both security updates and FIPS-validated cryptography while reducing disruption.

FIPS 140-3 validation can be a critical requirement for customers in regulated environments, including federal contractors. Previously, this re-certification process meant customers had to wait 12-18 months for each new kernel version to complete validation before they could adopt it. With the modular approach, once the module is validated it is designed to carry forward across kernel updates, whether minor or major releases, through a streamlined update process rather than repeating the full certification cycle, as long as the module itself remains unchanged. This is particularly relevant as customers face growing pressure to apply security patches rapidly while helping to maintain continuous compliance.

The FIPS re-certification process can be time-intensive with unpredictable timelines given current NIST Cryptographic Module Validation Program (CMVP) processing volumes. To help address this, we isolate all FIPS-scoped cryptographic algorithms, self-tests, and integrity checks into a single loadable kernel module that defines its own FIPS 140-3 cryptographic boundary with a stable interface to the kernel. This reduces what must be re-validated because instead of certifying the entire kernel binary which contains millions of lines of non-cryptographic code, only the standalone module containing the cryptographic implementation falls within the certification scope. For subsequent kernel versions using an unchanged module, re-validation can follow a more streamlined process rather than requiring a full certification cycle, helping our customers adopt kernel updates without the re-certification delays they previously faced, as long as the certified module itself remains unchanged.

We submitted the module for FIPS 140-3 validation. Based on current CMVP processing timelines, validation is expected to complete in 2027. The module interface boundary is designed to remain stable across kernel versions. Changes to the module are required if the kernel internal cryptographic API changes or if new algorithms need to be added to the FIPS scope. In many of these cases, changes can be absorbed by the interface layer without modifying the certified module itself, reducing the need for full re-certification.

Technical overview

The modular capability is included in AL2023 kernel 6.18 and later versions. The module loads automatically at boot with no kernel rebuild or configuration change required. To operate in FIPS mode, follow the enablement guide referenced in the customer guidance section below. This change does not affect other FIPS user-space modules such as OpenSSL, libgcrypt, and NSS.

The following diagram illustrates the architectural shift:

Figure 1. Kernel cryptography architecture before and after modularization.

The implementation spans two areas described below. The kernel build process produces the module as a separate artifact, and a boot-time mechanism loads and connects it to the running kernel.

A restructured kernel build

In the standard kernel build, crypto source code is compiled and statically linked together with other non-crypto components that are not in scope for FIPS to produce the final kernel image. With this change, the build process separates the FIPS-relevant cryptographic components from the kernel image by defining customized compilation rules. Crypto components that are FIPS-related and were previously built into the kernel are now automatically collected and linked separately into a standalone crypto kernel module. The new build process requires no changes to existing build workflows.

Boot-time module plug-in mechanism

Immediately after kernel boot starts, the crypto kernel module is loaded and initialized. Low-level interfaces such as function addresses are connected back to the kernel binary interface so that the module integrates seamlessly with the running kernel. Once loaded, kernel crypto subsystems and their services behave as if they were built in, with the same algorithmic implementations and call paths. This process was designed to not have a material impact on performance. This loading process is independent of FIPS mode configuration because FIPS mode controls how cryptographic algorithms behave at runtime while modularization determines how they are built and delivered within the kernel. To learn more about the design and implementation, see the detailed writeup on LWN.net.

Industry impact and benefits

Once the module completes validation, modularized kernel cryptography can help customers in regulated industries update kernels more frequently while maintaining their FIPS validation status. Customers who previously faced 12-18 month re-certification delays with each kernel version can instead adopt updates as they are released, whether they operate in financial services, healthcare, government, or any sector requiring FIPS-validated cryptography. This can help customers who want to apply critical security patches without a full certification cycle before deployment.

Customer guidance

When evaluating kernel options, customers should consider their specific regulatory requirements, the validation status of cryptographic modules, and their system requirements in accordance with all applicable authorization processes.

Customers who require a completed FIPS 140-3 certificate should continue using AL2023 kernel 6.1, which maintains active validation through 2029-09-22. The modularized crypto module is included in kernel 6.18 and initializes automatically at boot. The module is designed to not require configuration changes and preserves current behavior for non-FIPS workloads. Customers planning FIPS adoption can begin evaluation and testing ahead of formal certification.

Once validation is complete, customers can transition production workloads to kernel 6.18 or later with the validated module by following the FIPS Mode enablement guide for configuration.

Conclusion

To enable FIPS mode on AL2023, refer to our FIPS Mode enablement guide. For regular updates and best practices, follow the AWS Security Blog and FIPS-related FAQs on Amazon Linux 2023. You can also reach out to your AWS account team for help finding the resources you need.

If you have questions about this post, contact AWS Support.

Post Syndicated from sabeen malik original https://www.rapid7.com/blog/post/so-nis2-compliance-turn-readiness-into-resilience

The NIS2 directive asks covered organizations to take a more structured approach to risk management, governance, supply chain security, and incident reporting. It expands the scope of who may be covered, raises expectations around management body accountability, introduces clearer and more enforceable requirements, and increases pressure on organizations to show that security is being managed in a consistent, defensible way. Reporting timelines are one of the most visible parts of that shift, with early warning required within 24 hours of awareness for significant incidents, incident notification within 72 hours, and a final report within one month. It also arrived in a landscape that is still uneven, with member states continuing to implement the directive in different ways across the EU.

That combination has created a familiar challenge for CISOs and security teams, as the questions coming from boards and leadership are no longer just about whether the organization understands the regulation, but whether it can meet the requirements in practice. NIS2 reaches into risk management, reporting, governance, and supply chain oversight, which means readiness depends on how well security works across the business, not just on how well a policy is written.

That is why the most useful way to think about NIS2 is as an operational resilience exercise. Compliance still matters, of course, and teams need to know what the directive requires. What tends to make the difference over time is whether security leaders can connect those requirements to the real conditions of the environment: what is exposed, where ownership sits, how incident response works in practice, how supply chain risk is monitored, and how quickly the organization can move when something material happens.

Regulations are easier to absorb than operating model changes. A team may understand that NIS2 raises expectations around governance and incident handling, while still finding it difficult to answer basic questions quickly when pressure rises. Which business services are most critical? Which third parties matter most? Who owns the decision when a serious issue lands? How prepared are we to investigate, communicate, and report inside the timelines the directive expects? Those are the questions that separate a compliance project from a resilience program.

That is also why we have been building practical content to help teams move from interpretation to action.

Our ebook is the best place to start if you want the wider context. It is designed to help security leaders understand what NIS2 means in practical terms, how to think about the directive beyond a narrow checklist, and how to connect compliance obligations to a broader resilience strategy. If your team needs a stronger narrative for internal stakeholders, or a clearer way to explain why NIS2 should influence operational priorities, the ebook is the most useful first read.

Next, our NIS2 Readiness Toolkit is built for teams that want to assess where they are and what to do next. iIt is as a way to bridge the gap between NIS2 requirements and operational reality, with a focus on risk, reporting, and governance. It is designed to help teams spot gaps, focus effort, and simplify the path from regulatory complexity to a more defensible security strategy. In other words, it gives you a practical framework for understanding where readiness is strong, where it is uneven, and what deserves attention first.

Our infographic, seen below, is the quickest asset to use when you need to communicate one of the most tangible parts of NIS2: the 24-hour reporting requirement. Some stakeholders need the long-form explanation. Others need a practical view of what has to happen between incident awareness and early notification. The infographic helps teams bring that operational pressure into planning conversations, leadership updates, and internal alignment without requiring everyone to start with a longer asset first.

⠀

Taken together, these assets are useful because they serve different parts of the same problem. The ebook gives you a strategic view, the toolkit helps you assess readiness and prioritize action, and the infographic helps communicate the big picture quickly and clearly.

Enforcement expectations, reporting maturity, and national interpretation continue to evolve, and security teams are working through those changes at the same time as the wider threat landscape becomes more complex. A stronger response starts with clarity, but it needs to move quickly into coordination, ownership, and repeatable process if it is going to hold up under pressure.

If your organization is still treating NIS2 as a point-in-time compliance exercise, now is a good moment to widen the lens. The directive is pushing security leaders beyond a comply-once approach and toward a model of being continuously secure. Teams that build better visibility, stronger governance, and clearer response processes for NIS2 will be better prepared not only for regulatory scrutiny, but for the wider operational demands that are already shaping the market.

Post Syndicated from sabeen malik original https://www.rapid7.com/blog/post/so-aligning-security-programmes-with-nis2-requirements

If your organization operates in the EU, or works with organizations that do, NIS2 is no longer something on the horizon. It is here and it applies to a far wider range of sectors than its predecessor, the original NIS Directive (Directive (EU) 2016/1148), and it comes with real consequences for organizations that cannot demonstrate they are meeting its requirements. The good news? You do not have to figure out how to approach it alone.

Rapid7 has developed a dedicated NIS2 resource page that shows how the Command Platform can support key technical and operational aspects of NIS2 readiness, highlights common security program gaps, and explains where our solutions can help strengthen visibility, prioritization, detection, and reporting readiness. It is not a substitute for the broader organizational, legal, and governance measures the directive also requires, but it can be a useful starting point if you are evaluating your security capabilities and want a clearer picture of where tooling can support your approach. If you are in the early stages of assessing readiness, or further along and looking for a clearer view of the technical side, it is worth 10 minutes of your time.

What are the NIS2 requirements organizations need to meet?

NIS2, formally Directive (EU) 2022/2555, expands the scope of EU cybersecurity regulation significantly. More sectors are covered,the requirements are more demanding, and, crucially, the expectations have shifted from “do you have policies in place?” to “can you demonstrate that your controls actually work, continuously?”.

Article 21 mandates specific risk-management measures, including risk analysis, incident handling, business continuity, supply chain security, vulnerability handling, access control, and policies regarding the use of cryptography and encryption.. Article 23 introduces strict incident reporting timelines: an early warning within 24 hours, a full notification within 72 hours, and a detailed report within one month of a significant incident.

For many security teams, these timelines necessitate a shift in operational readiness. Timely and accurate incident reporting requires pre-established detection workflows, investigation processes, and contemporaneous documentation practices to be in place prior to an incident..

NIS2 also raises the stakes at a leadership level. Executive accountability for cybersecurity is now formalised. This is not just a technical team problem. It is a governance issue that touches CISOs, boards, and senior leadership across every in-scope organization.

Why traditional compliance approaches fall short of NIS2

Many security programs were designed around a different set of expectations. Periodic vulnerability scans.,annual audits, and compliance reports that reflected a moment in time rather than ongoing operational health.

NIS2 necessitates a move toward continuous, defensible risk management. This involves maintaining comprehensive asset visibility, identifying threat-aware exposures with high likelihood of exploitability, and validating the effectiveness of detection capabilities to support regulatory reporting requirements..

It is a meaningful operational shift, and it is exactly the kind of shift where having the right platform and the right partner matters.

How does Rapid7 support NIS2 compliance?

Rapid7 views NIS2 as an operational readiness challenge. The objective is to assist organizations in transitioning from periodic compliance assessments to continuous resilience: a sustained, measurable security posture designed to support regulatory alignment and strengthen defense-in-depth against emerging threats. The platform integrates exposure management, vulnerability management, cloud security, SIEM, and managed detection and response to provide broad support for the core requirements of Article 21 within a unified, connected view of risk..

That means organizations can move from scattered, point-in-time security activity to continuous visibility, threat-informed prioritization, faster incident workflows, and the kind of evidence and reporting that NIS2 and regulators actually demand.

A few areas where this makes a real difference:

Knowing what you are actually exposed to

Rapid7 is positioned as a Leader in the 2025 Gartner® Magic Quadrant™ for Exposure Assessment Platforms, a technology category fundamental to the Continuous Threat Exposure Management (CTEM) framework, which supports the proactive risk-management objectives of NIS2. Surface Command provides centralized visibility across internal and external environments, supporting the identification of unmanaged assets, shadow IT, and security control gaps that may otherwise remain undetected. Exposure Command utilizes active risk scoring and attack path analysis to identify and prioritize exposures based on reachability and threat context, helping teams focus remediation efforts on high-impact risks.

Responding and reporting faster

Rapid7’s SIEM and MDR capabilities are designed to support the detection, investigation, and reporting speed necessitated by NIS2. 24/7 monitoring and managed response facilitate the capture of essential telemetry and investigation trails within the SIEM, streamlining the evidence collection process for regulatory reporting.

Demonstrating that controls work

NIS2 is not satisfied by a list of tools you have purchased. It wants evidence that your controls are effective. Rapid7 provides continuous risk scoring, detection metrics, and audit-ready reporting that translates security activity into governance-ready language for leadership and regulators.

Where to go next for NIS2 readiness

This post covers the highlights, but Rapid7’s NIS2 resource page goes much deeper.

It walks through each of Article 21’s requirements in plain language, maps them to specific Rapid7 capabilities, and shows how the platform supports risk analysis… MFA monitoring, and technical assessment of cryptographic configurations. Whether you are a CISO seeking a strategic overview, a security manager evaluating technical controls, or a compliance lead mapping regulatory requirements to platform capabilities, our guidance is designed to support your objectives. NIS2 is operational; your approach to resilience should be as well. NIS2 is operational and your readiness should be too.

See how Rapid7 supports NIS2 compliance here.