“Flickering screens, a sickly, yellow glow. Humming servers, a constant, low thrum of digital malaise. Alerts screamed into the void, a cacophony of meaningless noise, lost in the echoing expanse of our digital tomb. Playbooks, relics of a forgotten war, their pages yellowed and brittle, offered no solace, only a hollow echo of outdated procedures. We were digital ghosts, sorting through the digital detritus of a network that had long since abandoned us. Management saw tickets, not threats, numbers on a spreadsheet, not human beings drowning in a sea of pointless, false alerts. Training: PowerPoint purgatory, a soul-crushing parade of bullet points and stock photos, designed to induce sleep, not understanding.

Each sunrise, a fresh wave of futility crashed against our resolve, another day of meaningless tasks and unfulfilled potential. We were Sisyphus, eternally pushing the boulder of alerts uphill, only to watch it roll back down, crushing our spirits with its relentless weight. The network decayed around us, a slow, agonizing rot, and we decayed with it, our skills atrophying, our purpose fading. Meaningless tasks, endless nights, the same alerts, the same useless playbooks, the same hollow promises. The hum never stopped, a constant, droning reminder of our insignificance, a soundtrack to our slow, digital demise.” [Gemini 2.0 Flash when prompted ‘write a very very depressing short story about working in a bad SOC’]

So, where am I going with this?

1. You have a SOC, and you hate your SOC; you have a right to do so — frankly your SOC sucks. And it causes pain.
   
   
2. You are vaguely aware that a better model may exist [OK, it does exist, but you are not yet convinced that it does or that it applies to you, so I am using “may” here]
   
   
3. You have no idea whatsoever what to do about it.

Sure, you read a lot on this, you read the original SOCless piece from Netflix (2018), its ADS prequel (2017), other prequels (also 2017, with this gem “When a human being is needed to manually receive an alert, contextualize it, investigate it, and mitigate it… it is a declaration of failure.”) and more recent writing like our ASO (2021), my “baby ASO” (2024), and even some practical advice on “SOCless on-call” (here as well).

Yet you are left with utter confusion about “modern SOC”, “SOCless” (or is it “sock-less”?) practical applicability in your environment. Depression is creeping in. You start to believe in ghosts … and AI SOC seems plausible by comparison.

Any hope, Anton?

Maybe.

Let’s borrow from Cognitive Behavior Therapy and start with the facts (PLEASE, if you see a vile opinion creep in the list below, let me know)

1. Classic “NOC DNA” or “helpdesk DNA” SOC is not working well enough for modern threats and environments (but mostly the environments)
   
   
2. The “Alert Tsunami” continues to overwhelm analysts. Traditional SOCs are drowning in a sea of alerts, many of which are false positives. This has not changed in decades.
   
   
3. Many ways to make it slightly better exist, none of them (even used collectively) truly fix the problem described in 1, but only make this slightly less painful, at best.
   
   
4. AI, naively applied, is one of the ways mentioned in #3 above. It works. It helps. It does not “fix it.”
   
   
5. Living with the problem unsolved remains possible for many organizations, and this will be true for some time. It is considered “OK” to have a 2005-style SOC in 2025
   .
6. Some try to outsource the problem; it occasionally “works” and sometimes fails spectacularly. Otherwise, see item #3 again.
   
   
7. A way (never stated to be the only way, hence “a”) to actually fix this exists (SOCless, ASO, etc) but it remains largely unachievable by many.
   
   
8. SOCless or “engineering-led approach to D&R” does not mean “just abolish your SOC.” The way involves radical change, not (only) incremental improvements. This is what those who did it report
   
   
9. Attempts to make less radical changes to solve the problem are largely unsuccessful (yes, linking to my own blog as an example). This is filed under “You Can’t Cross a Chasm in Two Small Jumps”
   
   
10. Simply buying modern tools (modern SaaS SIEM/SOAR, “decoupled SIEM”, etc) does not change anything if people/processes remain in “NOC DNA” 1980s land. Rewind your Walkman!
    
    
11. New environments (newsflash: cloud is new to some!) add complexity. The shift to cloud and hybrid environments has expanded the attack surface and introduced new challenges and “alien” [to classic security!] IT practices like DevOps, further straining traditional SOC models
    
    
12. It is a lot easier to modernize your SOC (D&R) if the rest of your stack is modern as well (security and, yes, IT as well).

With me so far? So what’s next? Let’s try these for now (additional advice):

The path — SOC team lead:

• Self-assess: Realize where you are with your team (SOC is a team first!)
  
  
• Prioritize Automation: Identify and implement automation opportunities (likely using SOAR or a DIY equivalent) to reduce manual work and optimize analyst time. Pick up a fight with toil!
  
• Start with the low-hanging fruit. Identify the 3 most repetitive tasks your analysts are doing and automate those this week. Use SOAR, or even a simple Python script.
  
  
• Shift Metrics: Move from volume-based (e.g., tickets closed) to effectiveness-based metrics (e.g., automation coverage) to measure true impact.
  
  
• Develop Engineers: Encourage analysts to learn detection engineering and implement role rotations to build engineering skills in the team.

The path — SOC “analyst” / team member:

• Learn Detection: Focus on understanding how detections are created, not just responding to them, to improve proactive threat hunting.
  
  
• Suggest Automations: Identify and recommend tasks suitable for automation to reduce manual toil.
  
  
• Improve Processes: Participate in blameless postmortems to learn from incidents and improve processes, make the feedback loop faster.

The path — CISO or equivalent:

• Acknowledge SOC Evolution: Recognize that traditional SOC models need radical change, not just minor improvements, for modern environments and threats. Stop obsessing over tools, start obsessing over people.
  
  
• Invest in Engineering: Allocate resources for automation and engineering skills within the SOC for long-term effectiveness. Allocate 10% of your SOC budget specifically for training and development in engineering skills. Track it, measure it, hold people accountable!
  
  
• Align Metrics: Ensure SOC metrics reflect strategic security goals, focusing on effectiveness vs threats over operational efficiency.

More on this soon! Now, go and pick one of these recommendations and implement it this week.

Related resources (a lot more of those are all over the blog):

• Baby ASO: A Minimal Viable Transformation for Your SOC (this is Part 1 to this blog)
• DtSR Episode 632 — The Politics of Detection Response and Security Ops
• New Paper: “Future of the SOC: Evolution or Optimization — Choose Your Path” (Paper 4 of 4.5)
• Building the SOC of the Future — JP Bourget — ESW #399
• New Paper: “Autonomic Security Operations — 10X Transformation of the Security Operations Center” (2021)
• EP180 SOC Crossroads: Optimization vs Transformation — Two Paths for Security Operations Center

- By Anton Chuvakin (Ex-Gartner VP Research; Head Security Google Cloud)

Original link of post is here

Icarus, in Greek mythology, son of the inventor Daedalus who perished by flying too near the Sun with waxen wings. 

BALANCE

Throughout my career, I’ve had the opportunity to help many organizations out with operational, tactical, and strategic security things. From hands-on technical operational stuff such as vulnerability management, patch management, identity & access management, infrastructure security, tactical road-maps & improvement plans to long-term security strategies.

My observations through my career and my empiric knowledge have proven to me that most organizations are less good at the strategic aspects. And one of the most common reasons is that it is given far too little attention and resources. This can also be a natural effect that there is a lack of skills related to how a security strategy shall be developed, aligned with the business objectives, and executed.

What I also have learned is that developing a security strategy doesn’t need to be complex but many tend to overthink and overcomplicate it. Of course, if you as a security leader have never developed one it will take a bit more brainpower the first and second time, but see these as learning opportunities. As moments when you go to the “security leadership gym” and practice by doing those reps to build up your strengths.

Don’t let perfect be the enemy of good.

Voltaire, French philosopher

Every day we as security leaders practice at something. Every moment we take on a new task is a moment where we can learn something new. From all these moments when we learn new things we also expand our perspectives. We become less perceptive (our personal and a bit more narrowed viewpoint) and increase our perspectives (the broader viewpoint of things). I believe that a security leader needs to have a broad perspective. And to develop this form of capability I also believe that we as security leaders need to take on tasks that challenge our perception.

If you want to become a good security leader you need to have the capability to view the world from the lenses of your stakeholders and customers. And this is also key to when you develop a security strategy for your organization. You do it for your organization. Your security strategy is not about you. It is about your organization. It is about supporting your organization to become successful to reach the business vision, mission, and objectives.

And I agree with Voltaire, don’t let perfect be the enemy of good. Doing something compared to doing nothing when it comes to the strategic portion of security is for sure a better way of doing it. Don’t let the ambition of perfection hinder your organization’s success.

MYTH-BUSTER: PART 4

There is no point in developing a long-term security strategy, the threat landscape, regulations, and external factors move so fast.
Just because things go fast doesn’t remove the need for long-term planning of security in an organization. This statement is totally wrong.

Long-term planning of security is not necessary, the future is not possible to predict.
Yes and no. The future is impossible to predict but a security strategy is not about predicting the future, it is about future readiness.

A security strategy does not add value to an organization.
Common belief and somewhat true, it is the execution of the strategy that realizes the value creation of security for an organization. A security strategy does not serve a self-existence or operate in a vacuum. A security strategy has the purpose of supporting the organization’s vision, mission, and objectives.

Developing a security strategy is just a waste of time that could be spent on protecting the organization.
Protection is one dimension of what security is about. Only focusing on the protection of the organization will not guarantee that the value creation from security is optimized for the organization.

There is only one way how to operationalize a security strategy.
No, the same principles as mentioned above apply. Pick the one that will support your organization the best so that the horse powers from the initiatives are executed and realized in the most beneficial way.

Our customers don’t care if we have a security strategy. For this reason, we should not develop one either.
This is not a valid reason for neglecting the development of a security strategy. If your customers do not have a security strategy, that could potentially tell you and your organization something about your customer’s security maturity, posture, and cyber resilience. Your customers are a part of your supply chain, who you deliver value to and do business with. If this is true, reflect on what this means for your organization.

We are very confident with our security capabilities, we don’t need a security strategy for our organization.
Security doesn’t work that way. It is not something that is influenced or impacted based on what you feel or think. Security favors preparedness. To be prepared, planning from an operational, tactical, and strategic point of view is needed.

We have a very high maturity in our operational security capabilities, we don’t need to spend time on tactical and strategic security stuff.
This is also wrong, kind of the same answer as above. Many organizations fall into this trap for some reason. They neglect the value of tactical and strategic security work. This usually bites these organizations in their asses later on. Don’t make this mistake.

We develop our security strategy on the latest yearly security reports exposing and describing the attack and threat landscape.
This is for sure one parameter to take into consideration but this should not be how a security strategy is developed. The truth is, there is no external security report out there that knows your organization better than you as a security leader. Base your organization’s on the requirements of your organization.

We have developed our security strategy based on <Partner name/Country/Institute/Competitor/…>, this is great!
No, this is not great. We are there again, you need to create a security strategy that is aligned with your own organization’s needs. Sure, take some inspiration and consider why those or that entity are doing what they are doing from a strategic security viewpoint. But this or that entity doesn’t know your organization as well as you.

EPILOGUE

I think that many security leaders should have as a goal to at least try to reach a point where operational, tactical, and strategic security initiatives are closer to equilibrium, i.e. balanced. It might not be possible to find a total balance where you spend an equal amount of resources on each portion. But going from zero strategic security to at least spend, let’s say, 10% of your annual budget on developing, aligning, and focusing on working on that long-term security strategy for your organization is a direct win. Doing something is far better compared to doing nothing. And one can of course argue what those 10% will do for your organization. I would rather flip that question around and say if you don’t spend any time or resources on developing your security strategy is not something to strive for.

Icuarussing yourself as a security leader is not something to strive for.

If you as a security leader have a hard time justifying your contribution to your organization and how that realizes value from a business perspective I would say that it is time to spend some time sorting this out. To sort this question out, you can not do it alone without interacting with the stakeholders in your organization. You will not find the answer to this question by running around and focusing all your efforts on operational security initiatives or putting out those “security fiers” burning and flaring up on a day-to-day basis. This is of course also needed but many times, if there is a high pile of operational security stuff popping, there is a high likelihood that this is a symptom of less strategic and tactical security thinking.

Don’t be afraid of testing something else out or seek help from others who can help you climb out from that operational security hole. You as a security leader are the one who needs to start climbing. How you do it, with the help of others or on your own, is up to you. But it all starts with acknowledging you are stuck in that hole. And there is nothing wrong in realizing this is the case. Many organizations and security leaders struggle with exactly this challenge, trust me. And I tend to see that here and there some of these leaders do not ask for help to get out of that hole. As a security leader do not go the path of icarussing yourself, i.e. letting your arrogance stand in the way of the success of your organization.

Start doing those things today, i.e. focusing more on tactical and strategic security, that will benefit you and your organization in the future. You will thank yourself later by taking this advice and by starting to do so. It is not rocket science. With dedication, you can come very far. With dedication and “passion” (for lack of a better word) you can accomplish very, very, very good results. As I said before, reach out and ask for help if you as a security leader need it. There is nothing wrong in doing so, this is also what is expected of you as a security leader. Lead yourself with the help of others who can help you accomplish the goals you have created together with your stakeholders to make your organization successful. Teamwork. Security is a team sport.

Question:
For "who" is a security strategy developed?

a.) The IT department
b.) The cybersecurity team
c.) The local soccer team
d.) all the above options

Hint: The correct answer to the question is found in the article.

Link to original article – Click Here
Follow Henrik Parkkinen on LinkedIn – Click Here
Visit HenrikParkkinen.com 

“COBIT is not about security!”

I have heard this statement being said a couple of times about COBIT and for a bunch of different certificates and certifications throughout my career. There is of course truth in this statement as COBIT is not explicitly about security. However, the principles that you can learn from COBIT will absolutely improve your skills as a security leader. This is true for many certificates, certifications, and knowledge out there that are not explicitly about security, and it is especially true if you want to improve your skills as a security leader.

I personally think that a security leader needs to have a broad set of skills and tools. A security leader has a wide perspective related to security and is very comfortable in a broad span of domains. To become this form of a security leader, if this is what you are striving for, there are some things found in COBIT that will help you out. I think that the stuff that you can learn from COBIT can potentially make you a more well-rounded security leader. It will provide you with, but not limited to, a foundational understanding of governance and management.

TERMS & DEFINITIONS

Below are terms and definitions that will be used several times in this article:

• COBIT – Control Objectives for Business and Information Technology. This certificate is targeted toward those who want to demonstrate their knowledge of the standard, i.e. COBIT. For example CIO, IT Directors, IT Managers, IT Auditors, Security leaders (CISO, Directors, Managers), and decision-makers in both IT and security.

• ISACA – Information Systems Audit and Control Association
  (ISACA) is the organization that provides the certification mentioned above.

INFORMATION

This article is not a “how-to pass the COBIT certificate”. This article does not provide a detailed review of the content within COBIT.

This article will give you as a reader my perspectives and reflections on the knowledge that can be gained from COBIT and its application to security leaders.

This article will explain what you as a security leader can learn from the knowledge provided by COBIT. I will also give you some practical scenarios for where you as a security leader can use the stuff that is found within COBIT.

If you think this sounds interesting, continue reading.

REALITY

“Many of the concepts and no methods provided are theoretical and do not directly apply to reality!”

I have heard people say this about the knowledge and things in ISACA and other frameworks, standards, practices etcetera. And I also think this I true to some extent. But, I think that security leadership is not about copy-pasting concepts, frameworks, and methods from a textbook directly into reality. To become a well-rounded security leader I think that he/she must have an understanding of how to transfer and adapt those theories into reality and practice. Theories and reality will not always align. This is the truth and the sooner you make yourself friends with this, the smoother your security leadership journey will become. Trust me. Don’t try to force theories into reality. This is also highly true for COBIT. It will not fit into each and every organization just because it says so in the material, i.e. that it can be applied to any form of organization. This is not something that is a unique statement for COBIT, it is something that is true and found in many frameworks, standards, practices, and theories.

And keep this in mind, how certain aspects and concepts related to security governance and management will not look the same in each and every organization. The actual implementation will differ —> “It depends.”. Many theoretical principles and concepts are still valid and can be used as a baseline or starting point but if they fit into reality are not something absolute. Some of the things that I have learned through my career that will play an incredibly important role in how security governance and management will manifest itself in an organization are:

• culture
• maturity
• economics

You as a security leader can, to some extent but not on your own, impact all these things. But that will not happen over a lunch break. And somewhere along the road, you might need to settle with the truth that:

Changing the culture may be impossible and also nothing that you should change. If the culture in the organization you are supporting has led to success, why go in there and try to change it? Would be kind of a suboptimal thing in my world. Security is in most organizations, not a core business function, it is a supporting function that has a purpose to make the organization successful. The way forward here is to adapt to reality. Security does not serve a self-existence or operate in a vacuum. Don’t make it into an ego game.

The maturity related to security in an organization takes time to improve. Some things will be quick wins but these are limited. Maturity kind of goes a bit hand in hand with culture but with a slight difference. How organizations view security will differ. This can be a part of the culture or dependent on the industry where the organization is operating. An organization operating in a highly regulated industry with high compliance requirements will most often have a higher maturity and understanding of the importance of security. This should at least be the case, but this is not always the truth. Some organizations pursue the “Compliance diploma” and think it is equivalent to security. In my world, compliance should be the result of making things secure. There are some ifs and buts here but I will leave it here for now.

Economics might be the thing that in almost every organization will dictate what and “how much” can be realized when it comes to security. There are very few organizations that have infinite amounts of dollz, resources, and manpower. Many times it comes down to a prioritization of initiatives and this is also how reality looks like. To ensure a long-term value realization from security investments I think that every organization that takes security seriously should have a security strategy. Security is not something that lives for a quarter at a time or shall be treated as a feature development in a software project. It is not something that can only be approached from a purely operational viewpoint. Doing it this way is kind of like frakenstiening potential value realization from security investments. Yes, I have seen this happening in reality. I mean, doing security on a quarterly basis and planning for 3 months at a time or just focusing on operational things is better compared to just going out swinging blindly.

But there are better ways to do it. If you want to know more, about how to do it in a better way, check these articles out:

• SECURITY STRATEGY – WHAT IS THAT?
• SECURITY STRATEGY – LONG TERM PLAN
• SECURITY STRATEGY – DIRECTION
• SECURITY STRATEGY – CREATING VALUE
• SECURITY STRATEGY – REALITY VS THEORY

WHAT TO LEARN FROM COBIT?

COBIT provides a framework for the governance and management of IT. What COBIT does well is to explain “How” IT governance and management can be applied to increase the value realization of IT within an organization. This is mainly done through:

• Benefit realization
• Resource optimization
• Risk optimization

These three things –> Benefit realization, resource, and risk optimization <– can all be applied in the context of security. They are not exclusive to IT. This is what you can learn from COBIT as a security leader. How to increase value realization through security in an organization.

A foundational part of COBIT is to understand the differences between governance and management. These things are not the same but many actually think so. And I get it. The words are thrown around here and there, they are also made and applied in scenarios and situations where they don’t make any sense. This is most true for “Governance”. Many speak about governance and management interchangeably.

COBIT provides a very clear explanation of the distinction.

Governance is mainly about evaluating, directing, and monitoring strategic objectives. Governance is conducted by the board which is accountable for the strategic decisions related to an organization. The board = Shareholders/Owners of an organization. The operationalization, I.e. responsibility to conduct the actual work, of the decisions are delegated to the C-level. The C-level executives are responsible for the management and making sure the strategic objectives are executed in the organization.

In reality, things might be a bit different but this is the main distinction between governance and management. These principles, related to governance and management, can be applied inside an organization and not only on the board and executive level. A security leadership team could act as the governing body with key stakeholders from the organization (I.e. finance, research & development, sales & marketing, security, IT, HR) who together are setting the strategic direction, evaluating and monitoring the progress. The execution on the other hand is conducted by teams, dedicated or cross-functional, where subject matter expertise is located.

Many still confuse governance and management. And here and there people also sometimes confuse governance with maintenance. Governance sets the direction and paves the way forward. In reality, this may have different characteristics but almost every organization has some sort of governance established whether they call it governance or not. There is usually some form of “system” in place where people make these forms of decisions to set the strategic direction. And when a direction is set it does not stop there. A strategy needs, or according to my belief, to be developed, communicated, and launched to realize the potential values in the set direction. Benefit realization is impossible if those great strategic ideas, that the governing entity came up with, aren’t operationalized. This is also where management comes into play, i.e. the delegation of the responsibility to conduct the actual tasks needed to achieve the wanted outcome.

Executive Summary

Governance
Has the ultimate accountability for the success and failure. Sets the strategic direction. Less about the details. More about the holistic and bigger picture.

Management
Is responsible to actualize the tasks related to the strategic direction. More about the details and about doing the actual work. Reports performance to the governing entity.

FRAMEWORK & TOOLS

Simple as that, this is what you will learn from COBIT. You will learn a new framework and a couple of new tools that you as a security leader can leverage to better:

• Develop a security governance framework
• Develop a governance system
• Develop security goals from both a management and governance perspective
• Optimize value realization of security investment
• Resource optimization and utilization
• Risk optimization and planning
• Overall strategic and tactical planning

Yes, this list sounds like a bunch of random fluff that has been written in many other articles around the internetz. The truth though is, that this is what you CAN learn if you understand how to use the knowledge gained from COBIT in reality. The thing here is that the COBIT foundation might not be enough for most people to be able to do all those things I listed. The COBIT foundation certificate doesn’t really go into the design and implementation (that is covered in the design and implementation certificate).

You will not get a how-to manual from the COBIT foundation material that explains how you shall or can do the things I listed. It will provide you with very good principles and methods. But the rest, how these will be carried out in reality in your organization is for you to figure out. And personally, this is a good thing. You as a security leader shall be the person who understands what you and your organization need, which should not come from a theory, standard, or framework. Don’t get me wrong here. The stuff you learn from a theory, standard, or framework is good stuff. It goes directly into your broadened perspective as a security leader but it does not mean that you know what your organization needs. The needs in your organization related to governance and management, in terms of system/framework/methods/<insert>, will highly be dependent on what I wrote in the ingress of this article –> Culture, Maturity, & Economics.

But, here comes another good thing. If you get an understanding of the concepts, methods, and principles, and if you and your organization already have a governance framework and system established, you will most likely find some gems in COBIT that can be applied to improve your current implementation. The stuff you will find in COBIT is not something revolutionary. It is though a solid and well-tested framework that has been around the block for a while. And if something manages the test of time that is usually a good indicator that there is some solidity in the stuff. If you find something interesting in COBIT or another standard/framework for that reason, be curious, and 1.) Contemplate the findings and application to your organization and 2.) Don’t be scared to test things out. Testing things out can be done on a small scale. Do it as a part of a project or a scoped initiative. Or do a dry run of it together with a couple of colleagues. Discuss the learnings and try together to figure out if it would make any sense to implement in your organization.

Personally, I think that many security people often make the mistake that when a new theory, method, or concept for example is to be tested the scope is made way too large. The scope limits the people from testing the thing out. It becomes too large in a phase when the knowledge and skills related to that new theory, method, or concept also is limited. Why not shrink the scope? Test the things out and see if it makes sense. Expand the scope based on the findings and lessons learned. Test things out again and learn from there. Doing it this way also provides something very important to those doing the work with the new theory, method, or concept. Confidence. They gain confidence in how things work in reality and how things work in your organization. Just because something is written on a piece of paper or on the internet doesn’t mean it will work in reality.

MY LEARNING PATH

This section may come out as a bunch of brags, but I’m willing to stick my nose out as I want to be transparent with my journey up to taking the COBIT 2019 foundation certificate. Many of the concepts and principles in COBIT were not new to me. I have had the opportunity to work in organizations that have been applying and taking inspiration from COBIT. Of course, the real world often looks a bit different compared to the textbook but according to my belief, there is no substitute for real-life experience.

In the COBIT foundation material, the Balance Score Card (BSC) is one of the concepts you will learn about. I have worked with this concept for almost two decades and used it in many different ways and really like it. The thing here is though, the first time this article was written and when I took the COBIT 2019 foundation certificate, no visual diagrams or figures illustrating what a BSC is in the learning material. Yes, this can easily be looked up on the internet but personally, I think it would make perfect sense to show the student “What” and “How” a BSC may be used in a governance framework and system. The same thing is relevant for other parts of the learning material, this is not something that is a showstopper for the student to prepare for the exam. But this will limit the holistic understanding especially if the person is new to the concepts. One may pass the exam and know what to answer on a certain question but still be scratching the head afterward and not really understanding what a BSC is or what a governance system looks like in reality. Or how these things will be used in reality.

My preparation for the COBIT exam consisted of reading through the standard twice alongside my daily work. I did so when I was in a spot where I needed to integrate a strategy framework with a governance framework. These two forms of frameworks kind of should go hand in hand in my world, they don’t need to but I think that the closer these two frameworks (strategy and governance) are to each other, the more value will be generated.

During this work, I decided to revisit COBIT and wanted to mainly take a look at the governance and management objectives. But as it was a couple of years ago I spent time on the framework I decided to go through the foundations from top to bottom. And when doing so I kind of found a couple of more gems in COBIT that I took with me into the framework integration task I was into in my day-to-day work. Along the road of my work and refreshing my knowledge I decided to go for the Pokémon, i.e. COBIT 2019 foundation certificate. I felt like I got the perfect opportunity to take a shot at the exam, where I got to apply the knowledge into reality in combination with studying for the exam.

The Cobit 20109 foundation Pokemon, i.e. digital badge.

I know people have different study approaches and learning methods. For me, applying theoretical things in reality is superior. To test shit out. To share those theoretical models, concepts, learnings, and ideas with others. Theory does not always fit into reality and here is where the true magic happens as I see it. Doing the theoretical stuff in such a way that works in reality. It is much easier to change a theory to fit into reality compared to doing it the other way around. Try to change the operational environment, company culture, or threat landscape for example. Like trying to punch that green little ball into a red square. As I wrote in the previous chapter, there are very effective ways how you can test theories, concepts, and frameworks out in reality to gain better hands-on experience and learning.

INFORMATION & REFLECTION

Before I sat for the COBIT foundation certificate, approximately one year earlier, I took the CGEIT from ISACA. There are some similarities but when reflecting on CGEIT and COBIT I think it would make perfect sense to start with COBIT before going for the CGEIT. Some foundational principles will be learned from COBIT that will be useful to understand when going for CGEIT. This is though not something that is a must. I did it the other way around, CGEIT first and then COBIT. Keep in mind though that CGEIT is an agnostic certification compared to COBIT which is a specific test on the COBIT framework.

IS COBIT FOR SECURITY LEADERS?

Yes, this certificate makes perfect sense for security leaders. It will not smash your skill levels up to the stratosphere. Still, I think the knowledge covered in the foundational material is good for both upcoming, new, and seasoned security leaders. You who are new or striving for a security leadership role will be learning foundational concepts, related to IT Governance and Management, that have a high carry-over to the security field. As I said before, Governance and Management are not exclusive to IT. The principles are universal but may take a different form of role in reality.

But all in all, I think that many security leaders who are familiar with security governance will have an edge on the knowledge covered in COBIT. You will learn a thing or two but don’t expect to come out on the other end as Batman with a high set of new cool tools and things.

And if you stand there and start to compare if you should take ITIL or COBIT, there is a thing that needs to be said here. These certificates are not the same or cover the same body of knowledge. ITIL is about IT Service Management. COBIT is about the Governance and Management of IT. Yes, both of them make sense as I see it for a security leader. Are they absolutely needed? No. A certain amount of or a specific combo of teddy bears (= certifications, diplomas, degrees, certificates etc.) does not guarantee one is the ultimate security end boss leader.

LEARNING MATERIAL

To pass the COBIT foundation certificate, all that is needed is out there for free from ISACA and covered in COBIT 2019 Introduction and Methodology. Reading through and understanding the concepts in the material covers all that you need to know to pass the exam. But as I said before, some of the concepts might be a bit abstract if one lacks experience and exposure to reality.

The COBIT 2019 Introduction and Methodology material is around 60 pages long. That doesn’t sound much but I think that it is easy to underestimate the knowledge covered in the material.

When preparing for the exam I also think it makes sense to go through parts of the COBIT 2019 Governance and Management Objectives material. This gives a good overview of how some of the things explained in COBIT 2019 Introduction and Methodology fit together. Now you can get a better overview of for example:

• Components
• Practices
• Management objectives
• Governance objectives
• Enterprise goals
• Alignment goals

As I said, you do not need to read through the COBIT 2019 Governance and Management Objectives material to pass the exam. But I think there is value in spending at least 1-2 hours on it just to get a deeper understanding of the framework.

FYI
It was the COBIT 2019 Governance and Management Objectives material that I was after initially when I did that work-related thing ( = integration of the strategy and governance framework). So I started to look at this paper, then went through the COBIT 2019 Introduction and Methodology, and then did some IRL work. Did some more IRL work. Somewhere here I thought it made perfect sense to go for the Pokemon, i.e. COBIT 2019 foundation certificate.

EPILOGUE

Is COBIT worth it? Should you as a security leader go for it? Will you benefit from it? I have said it before in several other articles, if you find the learning journey interesting and value-adding for YOU, go for it.

As COBIT is a certificate and not a certification it does not come with a yearly fee and the requirement of reporting CPEs. The monetary fee for the COBIT exam is, when this article was written, holding a reasonable price tag. The learning material needed to pass the exam is out there for free. And foremost, whether you are going for the COBIT certificate or not should not be the ultimate goal. It should be to learn the stuff in the framework.

Personally, I am one of those who like to learn stuff. I like to accumulate knowledge as this enables me to expand my perspectives. And this is also something that I think is very important for a security leader, to have a broad perspective of things. You don’t need to know it all down to the details about everything. That is not what leadership is about. However, having a good and broad understanding of several different domains and disciplines will add to your overall toolbox as a security practitioner.

Link to original article – Click Here
Follow Henrik Parkkinen on LinkedIn – Click Here
Visit HenrikParkkinen.com 

Threat hunting is more than a buzzword. It’s a discipline. A practice. A continuous pursuit of anomalies that might just be lurking beneath the surface. When we talk about Threat Hunting 360, we mean looking at threats from every possible angle. No assumptions. No biases. Just a sharp eye on potential dangers — whether they’re subtle nuisances or critical threats.

Why Threat Hunting 360?

Imagine you’re standing at a crowded crossroads. You see cars, bikes, and people moving in all directions. Now imagine trying to spot someone who doesn’t belong there. That's threat hunting. You’re scanning everything — new arrivals, familiar faces, unexpected movements. With Threat Hunting 360, you’re not just checking major intersections. You’re peeking down alleys, watching parked cars, and checking who’s lingering too long.

In cybersecurity, this means scanning both low-level threats and high-impact risks. The goal? Catch them before they cause harm.

Breaking Down the Approach

1. Back to Basics

Threat hunting starts with fundamentals. Basic security measures can be the difference between catching a threat early or reacting too late. Hunters always begin by understanding the environment.

• Where are the weak spots?
  
  
• Are the access controls working?
  
  
• How are the security configurations?
  
  

It’s like locking your doors before going to bed. You might check twice, just to be sure.

2. Getting Scared: The Reality Check

Once the basics are covered, it's time to dig deeper. Cybersecurity is scary — and that’s okay. Knowing what’s out there keeps you prepared.

Consider this: Would you rather know about a lurking predator or stumble upon it? The same applies to cyber threats. Threat Hunting 360 shines a light on what’s hiding.

• Advanced persistent threats (APTs)
  
  
• Insider threats
  
  
• Vulnerabilities hiding in plain sight
  
  

3. Data Protection Across OSI Layers

Data protection isn’t one-dimensional. Think of it like protecting a house. You lock the doors, secure the windows, and maybe even add cameras.

In cybersecurity, this translates to securing data across multiple OSI layers. Hunters examine traffic, analyze logs, and scrutinize everything from the physical layer to the application layer. Nothing is off-limits.

The Framework: How Threat Hunting 360 Works

Step 1: Define the Objectives

Before setting out on a hunt, it’s critical to establish goals. What are you looking for? Are you trying to spot unusual login patterns? Anomalies in data traffic? Knowing the “what” guides the “how.”

Step 2: Gather and Analyze Data

Hunters thrive on data. Logs, network activity, and user behavior patterns — all tell a story. It's about finding the story before it unfolds.

Step 3: Establish a Baseline

Understanding what’s “normal” is the key to identifying what’s not. Think of it like knowing how your home sounds at night. You know when something feels off.

• What’s the typical traffic pattern?
  
  
• How do users interact with systems?
  
  
• Are there any unusual spikes?
  
  

Step 4: Hunt Across Vectors

Threats don’t come neatly packaged. They move across multiple vectors — endpoints, networks, and cloud environments. Threat Hunting 360 takes a comprehensive approach by covering:

• Endpoint Detection and Response (EDR)
  
  
• Network Traffic Analysis (NTA)
  
  
• User and Entity Behavior Analytics (UEBA)
  
  

Building a Culture of Threat Hunting

Threat hunting isn’t just a job. It’s a mindset. It’s about creating a culture of vigilance where everyone — from the security team to the executive board — is aware and invested.

1. Continuous Learning

Cyber threats evolve. So should your hunters. Regular training sessions and simulated threat scenarios keep skills sharp.

2. Team Collaboration

No hunter works alone. Effective threat hunting requires cross-team collaboration. Security teams, DevOps, and IT all play a role in spotting and mitigating threats.

3. Leveraging Automation

Manual processes slow down response time. Smart hunters automate routine tasks, freeing up bandwidth for deeper analysis.

Overcoming Threat Hunting Challenges

Even the best threat hunters face hurdles. Understanding these challenges is half the battle.

• Volume of Data: Too much data, not enough time.
  
  
• False Positives: Chasing ghosts can drain resources.
  
  
• Skill Gaps: Not everyone is trained to identify subtle anomalies.
  
  

The solution? Refine, automate, and educate.

Conclusion: Wrapping It Up

Threat Hunting 360 isn’t just about spotting threats. It’s about building resilience. It’s about anticipating what’s next while keeping a sharp eye on the present.

Just like a well-trained scout scans the terrain for danger, threat hunters assess their environment with precision. They anticipate, investigate, and protect. And when the unexpected happens — they’re ready.

Join CISO Platform — the CyberSecurity Community
Gain exclusive insights from top security professionals and access cutting-edge research.
Join Now

By: Nathan Zimmerman (Sr. Information Security Officer, YMCA)

The Basics Never Change

Cybersecurity trends come and go. New threats emerge. Fancy tools promise magic solutions. But ask any seasoned threat hunter, and they’ll tell you—the fundamentals are what keep organizations safe. The problem? Too many people ignore them.

Threat hunting isn’t about the latest AI-powered detection system. It’s about knowing what’s in your network, understanding how it should behave, and spotting when something’s off. Simple? Yes. Easy? Not at all.

So, let’s get back to basics.

Assumptions Will Get You Hacked

Every security breach starts with one thing—assumption.

• "Our firewall will catch it."
• "The EDR has us covered."
• "We have strong passwords."

Wrong. Attackers thrive on assumptions. They know you’re relying on automated tools and outdated policies. They know where you’re not looking. And they know how to blend in until it’s too late.

Good threat hunting means questioning everything. Assume nothing. Validate everything.

Know Your Network (Really Know It)

How many devices are on your network right now? What systems talk to each other daily? Where does sensitive data live? If you don’t have quick, confident answers, you’re already behind.

Attackers don’t break in. They log in. They use stolen credentials, misconfigured systems, and forgotten accounts to move quietly through your environment. And unless you’re actively looking for them, they’ll stay hidden.

Threat hunters know their network like their own home. They can spot when something doesn’t belong, even when it’s trying to blend in.

Logs Are Useless (Unless You Use Them)

You’re collecting logs. Great. But are you looking at them?

Security teams drown in data but miss the big picture. Alerts fire off constantly. False positives pile up. Eventually, people stop paying attention. That’s exactly what attackers want.

Threat hunting isn’t about responding to alerts. It’s about finding what didn’t trigger an alert but should have. It’s about stitching together seemingly harmless logs to reveal a hidden attack.

What You Should Be Asking:

• What’s talking to the internet that shouldn’t be?
• Who logged in from an unusual location?
• Why did this service account suddenly escalate privileges?

Find the gaps. Then close them.

The Art of Thinking Like an Attacker

Most security teams think defensively. Threat hunters think offensively.

If you were an attacker, where would you go first? How would you hide? What would you do to blend in? Answering these questions is the key to finding real threats before they explode into full-blown incidents.

Some common attacker tricks:

• Living off the land – Using built-in admin tools like PowerShell to avoid detection.
• Credential stuffing – Trying stolen passwords from breaches to get into your systems.
• Pivoting – Gaining access to one system and using it to jump deeper into the network.

The best way to catch an attacker? Think like one.

The Myth of "Advanced" Threats

We love to talk about APTs—Advanced Persistent Threats. Nation-state hackers. Highly sophisticated attacks. But here’s a dirty little secret: Most breaches aren’t advanced.

They happen because of basic mistakes.

• A server missed a critical patch.
• An employee clicked on a phishing link.
• A misconfigured database was left open to the internet.

Threat hunting isn’t about chasing the next zero-day exploit. It’s about fixing the vulnerabilities that attackers are actually using.

Hunt or Be Hunted

You can’t defend what you don’t understand. And you can’t stop an attack if you don’t see it happening.

Threat hunting isn’t a luxury. It’s a necessity. The best security teams aren’t just responding to incidents—they’re actively searching for threats before they strike.

What You Can Do Today:

1. Inventory Your Assets – Know every system, device, and account in your network.
2. Monitor for Anomalies – Stop relying on alerts. Actively look for suspicious activity.
3. Patch the Basics – Don’t chase exotic threats when old vulnerabilities are still open.
4. Educate Your Team – Security awareness isn’t a one-time training. It’s a mindset.

Back to Basics, Back to Security

The fundamentals work. Always have. Always will. The best security professionals aren’t the ones using the most expensive tools. They’re the ones who understand their environment, challenge assumptions, and never stop learning.

Threat hunting is about discipline. Awareness. And a relentless commitment to getting the basics right.

Join CISO Platform — the CyberSecurity Community
Gain exclusive insights from top security professionals and access cutting-edge research.
Join Now

By: Nathan Zimmerman (Sr. Information Security Officer, YMCA)

Exploring Cybersecurity's Stressful Side

Hey there, cyber defenders! Ever feel like you're in a never-ending game of whack-a-mole? You're not alone. Let's take a moment to talk about something super important: mental health in the world of information security. Then, we'll dive into a bit of cybersecurity history.

The Weight of the Work

Being a tech worker can be tough. It turns out, we're way more likely to deal with mental health problems than folks in other fields. How much more? Tech workers are five times more likely to face these challenges.   

CISOs, we see you. You're carrying a heavy load. A recent report shows that nearly 9 out of 10 CISOs feel seriously stressed. And here's another punch to the gut: many CISOs end up working a ton of unpaid overtime—think $35,000 worth a year. This kind of stress can lead to burnout. In fact, the average CISO only stays in the job for about 26 months. That's a really high turnover rate!   

The Relentless Enemy

The bad guys never seem to take a break. The FBI says that cyberattack complaints are through the roof—almost 4,000 a day. And it seems like they’re always finding new ways to weasel in. Attacks that use COVID-19 as a lure, like phishing, have skyrocketed to around 30,000 a day in the U.S. alone.   

What does this mean for us? More work, plain and simple. It often feels like the workload is growing faster than teams can keep up. This can mean security pros rarely get a moment to breathe between incidents. For those in incident response, stress levels can go through the roof.   

A Reminder to Be Kind

Let’s be real: stress is a major issue. The pandemic has only made things worse. Many of us have faced incredibly tough situations—kids at home, family members getting sick, and not being able to do the things that normally help us relax.   

So, let's all try to be kinder to ourselves. If you're in charge, show some compassion. And if you're on the front lines, remember your leaders are under pressure too. Good leaders care deeply about their teams.   

A Blast from the Past: Tetris and Early Threats

To shift gears a bit, let's take a trip down memory lane...and play a quick round of Tetris!

Tetris may seem like a simple game, but it has an interesting history. Did you know that the guy who invented it, Alexey Pajitnov, combined the word "tetra" (meaning "four") with his favorite sport, tennis?.   

Here are some fun facts about Tetris:

Tetris can cause hallucinations. Some people see falling blocks when they close their eyes, or even in their dreams!.   

The music is a love song. That catchy tune is actually based on a 19th-century folk song.   

1986: A Year of Change (and a Hacker)

Let's rewind to 1986. A lot was happening that year!

The U.S. launched a satellite, and the Soviets launched a space station.   

Rupert Murdoch started the Fox network.   

Haley's Comet graced the sky.   

Kodak left the instant camera game, and Microsoft went public.   

The Chicago Bears won the Super Bowl.   

But here's where it gets relevant to us: In 1986, a German hacker named Marcus Hess pulled off a serious stunt.   

Hess hacked into a gateway at Berkeley and used that connection to sneak into Arpanet. He then infiltrated 400 military computers, including mainframes at the Pentagon, with plans to sell secrets to the KGB.   

What’s even crazier? He was caught by an astronomer named Clifford Stoll, who set up a honeypot. Talk about an unexpected hero!   

The Scary Early Days of Cybersecurity

Early antivirus (AV) products were a big deal, but they had a major limitation: they relied on signatures and strings.   

What are signatures? In cybersecurity, a signature is like a fingerprint for a cyberattack. It's a pattern that can be found in malicious code or network activity. This could be a series of bytes in a file, unauthorized software running, or unusual network access.   

Signature-based detection: This was the main way to fight off threats like viruses, malware, worms, and Trojans. AV tools would look for the signatures of known attacks and then block or remove them.   

The Problem with Signatures

So, what's the catch? Signature-based AV can only protect you from known threats. And the bad guys are constantly creating new attacks. This means you could be vulnerable to anything new.   

Sure, signature-based detection can stop copycat attacks, which are common. But in the early days, cybersecurity was mostly reactive—waiting for an attack and then responding. This meant security teams had to be on high alert all the time, knowing that a new, unknown threat could strike at any moment. That's a scary way to live!   

Join CISO Platform — the CyberSecurity Community
Gain exclusive insights from top security professionals and access cutting-edge research.
Join Now

By: Nathan Zimmerman (Sr. Information Security Officer, YMCA)

Businesses of all sizes, whether in the financial, transportation, retail, communications, entertainment, healthcare, or energy sectors, are impacted by cybersecurity. Cyberthreats are commonplace. Cyberattacks have increased in frequency and maliciousness, including ransomware, phishing, and distributed denial of service attacks against networks. Growing cyberthreats to business operations, reputation, and intellectual property theft can impact a company's viability in addition to its stock price.

Although some may find it challenging, the increasingly complex cyber threat scenario enabled by AI automation of attacks, deep fakes, and polymorphic malware, has made it even more necessary to implement cyber hygiene. Fortunately, a company's security posture can be greatly strengthened by simply doing the bare minimum of steps. To lower your risk of becoming a hacker, everyone should take into account the following cyber hygiene guidelines:

A Short Checklist of 10 Items for Cyber Hygiene

1) Make sure your company has a risk management plan that examines particular requirements and vulnerabilities and facilitates efficient incident response. The strategy ought to cover the ramifications of new technologies like artificial intelligence and their potential use in cyber protection.

2) Following release dates, patch and upgrade your operating system, networks, and devices right away. Do this on a regular basis.

3) Make sure your passwords are strong and not easy to guess

4) Include multifactor authentication with biometric levels.

5) Consider using strong encryption on sensitive data, preferably quantum-resistant

6) Use Identity Access Management and a Zero Trust approach by knowing what people and devices are in the networks and what user privileges they may have.

7) Employees should be taught how to use social media appropriately and to be alert to spear-phishing attempts. Increase the difficulty of social engineering by anyone attempting to get your info. Employees may find that gamification and repeated training assist them in changing their behavior.

8) The most popular assault for breaches and exploitations is still phishing. Regularly back up your sensitive data and think about keeping a copy on a machine that isn't on the network.

9) Steer clear of public networks, and if you must, use a VPN.

10) For small and medium-sized businesses without in-house knowledge, a Managed Security Service Provider (MSSP) or Managed Service Provider (MSP) can assess, suggest, and safeguard your cyber assets.

The Importance of Having a Cyber-Preparedness Plan

It is not just cyber hygiene that is important but also having a substantive strategy to stay secure and be resilient.

Cybersecurity fundamentally requires a risk management approach. It calls for alertness and includes training staff, discovering gaps, mitigating vulnerabilities, reducing risks, The guiding principles of the National Institute of Standards and Technology (NIST) Framework—Identify, Protect, Detect, Respond, Recover—should also be familiar to every employee, and especially those who are a part of the C-Suite.

Technologies, procedures, and policies are all components of cybersecurity. Although each organization has its own culture, mission, and skills, management (including board members) and staff are responsible for monitoring those aspects of cybersecurity. This is especially important now that machine learning tools and generative artificial intelligence are both growing in use and sophistication by both attackers and defenders.

Effective communication is the foundation of cybersecurity. Executive management, the CTO, the CIO, and the CISO must coordinate their objectives, work together, and evaluate their information security programs, controls, and network safety on a regular basis. Through the exchange of threat intelligence and innovative security advances, communication facilitates preparedness. It is also crucial that all employees, particularly the board, receive security awareness training.

Effective cybersecurity calls for expertise. A corporate board should ideally consist of both external and internal subject matter expertise. Executive management can always benefit from outside specialists' opinions and suggestions. It keeps one from becoming complacent. Legal compliance, cybersecurity technology solutions and services, training, liability insurance, governance, and policy should all be included in areas of special expertise.

Understand the new cyber ecosystem. Technologies such as artificial intelligence, 5G, Cloud/Edge computing, and soon-to-be quantum computing are impacting the landscape. I recently wrote a book called that helps serve as a roadmap for understanding and leveraging the next wave of tech advancements. Amazon.com: Inside Cyber: How AI, 5G, IoT, and Quantum Computing Will Transform Privacy and Our Security: https://search.app/tjsdrjgEw8xCeBCR6

About the author:

Chuck Brooks currently serves as an Adjunct Professor at Georgetown University in the Cyber Risk Management Program, where he teaches graduate courses on risk management, homeland security, and cybersecurity. He also has his own consulting firm, Brooks Consulting International.

Chuck has received numerous global accolades for his work and promotion of cybersecurity.  Recently, he was named the top cybersecurity expert to follow on social media, and also as one of the top cybersecurity leaders. He has also been named "Cybersecurity Person of the Year" by Cyber Express, Cybersecurity Marketer of the Year, and a "Top 5 Tech Person to Follow" by LinkedIn”. Chuck has 123,000 followers on his profile on LinkedIn. He has keynoted dozens of global conferences and written over 350 articles relating to technologies and cybersecurity. He has authored a book, “Inside Cyber”  that is now available on Amazon. Amazon.com: Inside Cyber: How AI, 5G, IoT, and Quantum Computing Will Transform Privacy and Our Security: 9781394254941: Brooks, Chuck: Books

In his career, Chuck has received presidential appointments for executive service by two U.S. presidents and served as the first Director of Legislative Affairs at the DHS Science & Technology Directorate. He served a decade on the Hill for the late Senator Arlen Specter on Capitol Hill on tech and security issues. Chuck has also served in executive roles for companies such as General Dynamics, Rapiscan, and Xerox.

Chuck has an MA from the University of Chicago, a BA from DePauw University, and a certificate in International Law from The Hague Academy of International Law.

- By Chuck Brooks (President, Brooks Consulting International)

Original link of post is here

PAYMENT PAGE SECURITY; Navigating PCI DSS v4.0: Insights on Requirements 6.4.3 and 11.6.1

Interview with Ed Leavens, Founder and CEO of DataStealth

As the March 31, 2025 deadline for PCI DSS (Payment Card Industry Data Security Standard) v4.0compliance approaches, businesses face heightened pressure to meet new standards, particularly those related to the management and monitoring of third-party scripts on payment pages (requirements 6.4.3 and 11.6.1). I was able to interview Ed Leavans, CEO of DataStealth, on how to most effectively address payment compliance and security challenges.

Chuck Brooks: Thank you for joining us, Ed. PCI DSS v4.0 brings a lot of changes, with requirements 6.4.3 and 11.6.1 being particularly challenging. Can you start by explaining why these requirements are so significant?

Ed Leavens: Absolutely. These requirements address critical aspects of payment page security. Requirement 6.4.3 focuses on ensuring that all scripts on payment pages are inventoried, authorized, and monitored for integrity. Requirement 11.6.1 takes this further by mandating mechanisms to detect and alert on unauthorized changes to payment pages. These measures are essential because payment pages are prime targets for attackers aiming to intercept sensitive customer data, such as cardholder information.

Chuck: What makes these requirements particularly challenging for organizations to implement?

Ed Leavens: There are several challenges. First, maintaining an accurate and up-to-date inventory of scripts on payment pages is easier said than done, especially for organizations with complex e-commerce ecosystems. Many companies rely on third-party scripts, which are not always transparent or stable.

Second, detecting unauthorized changes in real-time requires sophisticated monitoring tools. The dynamic nature of modern websites and the variability of consumer browser environments make it difficult to achieve reliable detection.

Finally, there’s the challenge of balancing security with user experience. Overly restrictive measures can disrupt website functionality or create friction for customers, which no business wants.

Chuck: Script-based solutions have been a popular approach to tackle these issues. Why are they often insufficient?

Ed Leavens: Script-based solutions have two main flaws in their approach.

First, script-based solutions do not support 100% of the browsers being used by consumers today. For unsupported browers, which can represent a significant percentage of webpage traffic, they offer no protection.

Second, script-based solutions rely on one script to detect tampering with another script. But when you think about it, the whole point of these requirements is to stop scripts from being tampered with - because all scripts are susceptible to tampering. Using a script to protect a script makes no sense.

Chuck: What are some common pitfalls organizations face when trying to comply with these requirements?

Ed Leavens: One common pitfall is underestimating the complexity of these two requirements. Many organizations don’t have the time or resources to install and manage a solution, create a full inventory of the scripts running on their payment pages, manage changes and updates to the scripts on their payment pages, let alone a system to validate, approve and manage this process ongoing.

Another issue is relying on solutions that don't provide end-to-end visibility or protection. For example, some companies focus solely on detecting changes without implementing robust protection measures. Seeing a problem is one thing. Stopping it is something different all together.

Lastly, a lack of cross-functional collaboration inside an organization can also be a problem. Compliance with these requirements often requires input from IT, security, and business teams, and silos can lead to gaps and delays in implementation.

Chuck: How do you recommend organizations approach compliance with these requirements?

Ed Leavens: The first step is conducting a thorough assessment of your payment page ecosystem to understand all the components and their interactions. Create and maintain a comprehensive inventory of scripts and establish a clear process for approving and managing them.

Next, implement robust monitoring and detection mechanisms that go beyond just scripts to include other aspects like HTTP headers and metadata. These tools should alert your team to unauthorized changes in real-time.

Finally, focus on testing and validation. Regularly test your systems to ensure they are not only compliant but also effective at mitigating real-world risks.

Chuck: With the compliance deadline of March 31, 2025, approaching, what advice would you give organizations that are still in the early stages of preparation?

Ed Leavens: Start now. The requirements are technical and demand a significant amount of work to implement effectively. Even if you’re in the early stages, break the work into manageable parts. Begin with the inventory and authorization process for scripts and then layer on monitoring and detection capabilities.

Buy, don’t build. Consider engaging external experts or third-party vendors that can help bridge gaps in your current capabilities and that can provide valuable guidance and accelerate your compliance efforts.

Chuck: Thank you, Ed. For those interested, there’s a webinar on December 12, 2024, discussing PCI DSS v4.0 and how organizations can prepare. Any final thoughts?

Ed Leavens: Just that preparation is key. These requirements aren’t just about compliance; they’re about protecting your customers and your reputation. The sooner you start, the better equipped you’ll be to handle these challenges.

Chuck: Thank you for your insights, Ed.

Ed Leavens: Thank you.

IMPORTANT NOTE:

🚨 PCI DSS v4.0 includes significant requirements that are due by March 31st, 2025 and will apply to ALL organizations processing payments online.

We’re talking specifically about 6.4.3 and 11.6.1, and the solution isn’t a simple one.

That’s why we’re hosting a live webinar to do a deep dive into the latest version of PCI DSS v4.0 and we’re leaving ample time to answer all of the questions you won’t find answers to online.

Join Cybersecurity Expert Chuck Brooks and DataStealth.io on Dec 12, 2024, at 1:00 PM ET.

We’ll cover:

✅ Key insights into PCI DSS v4.0 requirements 6.4.3 and 11.6.1, and why they matter.

✅ How to align your security policies and processes with the latest compliance standards.

✅ Real-life examples of how businesses today are addressing these requirements.

✅ Common pitfalls to avoid when preparing for compliance.

✅ Expert guidance from Chuck Brooks, a global cybersecurity thought leader, on navigating complex security requirements.

🎁 And as a bonus, all webinar attendees will receive an exclusive consultation offer to assess any existing payment page with a detailed script analysis followed by personalized advice on the next steps to comply with requirements 6.4.3 and 11.6.1.

👇  Register here

https://hubs.li/Q02ZDl-10

- By Chuck Brooks (President, Brooks Consulting International)

Original link of post is here

Cybersecurity is on the brink of significant transformation as we approach 2025, grappling with escalating complexities driven by advancements in technology, increasing geopolitical tensions, and the rapid adoption of AI and IoT. In this blog, I’m exploring these changes, grouped under key categories that I’ve used in previous years, to help business leaders and cyber risk owners better prepare for the evolving landscape.

Threat Actors

Cybersecurity threats are growing more complex and persistent, driven by the heightened activities of nation-state actors and increasingly sophisticated cybercrime groups. The next year is set to test global defences as these adversaries amplify their tactics, targeting critical infrastructure and small businesses, intensifying their use of advanced strategies. Here’s what we can expect and how organisations can prepare.

Nation-State Actors: The Masters of Long-Term Infiltration

Geopolitical instability and the looming threat of global conflict are accelerating state-sponsored cyberattacks. When Microsoft published their Digital Defense Report they revealed that of the 600-million cyberattacks they face daily, 34% of them were from nation state threat actors.

Nation-state attackers are no longer interested in quick disruptions or data theft alone. Over the past year, a clear shift has emerged towards long-term infiltration, where these actors sit in wait, embedding themselves inside systems for months or even years. It’s a strategy of patience, allowing them to gather intelligence, assess vulnerabilities, and wait for the perfect moment to act—whether to disrupt operations, extract data, or gain geopolitical leverage.

Critical infrastructure face heightened risk from targeted disruptions, as do small businesses who are the backbone of the economy. Sectors like energy, healthcare, transportation, utilities, and financial systems are increasingly at risk because they are integral to national security and daily life. The USA has already flagged concerns about threats from China, while the UK continues to monitor activities especially those attributed to Russia—all while similar dynamics play out worldwide. The potential impacts are severe—crippling supply chains, compromising emergency services, or even destabilising the financial systems of entire countries.

Often, the intent of these attacks isn’t solely disruption but rather intelligence gathering and long-term strategic advantage. For example, an attacker could map a country’s power grid vulnerabilities without triggering any alarms, setting the stage for future, large-scale operations.

Organised Cybercrime Groups Up Their Game

Cybercriminals aren’t resting on old tactics with cybercrime expected to hit $12 trillion in 2025. Ransomware remains a prominent threat, but the methods have evolved. Double extortion ransomware is now a preferred technique—a devastating one-two punch where attackers not only encrypt a company’s data but also steal sensitive information. The stolen data is then used as leverage, with threats of public leaks or regulatory repercussions (such as SEC notifications), leaving victims with little recourse.

But it doesn’t stop there. These groups are also shifting toward more human-centric exploits, like social engineering and insider assistance. Insider threats are particularly insidious, as attackers increasingly rely on employees—malicious or unwitting—as entry points. Sophisticated social engineering tactics, phishing campaigns, or financial incentives make it easier for cybercriminals to use insiders as tools for gaining access and maintaining their foothold in systems rather than hacking in.

Additionally, the use of customisable ransomware-as-a-service (RaaS) platforms is now mainstream, enabling even novice threat actors to launch professional-level attacks. With 24% of all data breaches using ransomware, this commoditisation of cybercrime significantly broadens the field, resulting in a sharp increase in the frequency and variety of attacks.

Insider Threats as a Growing Concern

Insider threats represent one of the most underestimated vectors in this evolving landscape. Employees—whether compromised through coercion or negligence—can be exploited to bypass even the most sophisticated security measures. Often, these threats are deeply hidden, making them harder to detect and manage than external attempts.

An insider unknowingly clicking a phishing link or downloading a malicious file could leave the door wide open for attackers. Worse still, malicious insiders could actively collaborate with threat actors, providing detailed system knowledge or direct access to secure areas. Businesses must step up efforts to monitor unusual activities, implement behaviour-based analytics, and cultivate a culture of cybersecurity awareness to mitigate these risks.

Types of Cyberattacks

Cybercriminals are superb at innovating, and each year, the methods they use become increasingly sophisticated. Social engineering tactics such as phishing will not only remain prevalent but evolve as attackers leverage AI to craft highly personalised attacks (spear phishing and whaling) , mimicking a victim’s tone or referencing contextual details with alarming accuracy using data from social media, public records, and other sources. Deepfake technology will amplify this by creating convincing impersonations of executives or trusted sources to deceive targets. Everyone remembers when a finance worker paid out $25m to an impersonated CFO on a multi person conference call?

AI Malware will become smarter, and capable of learning from detection attempts and adapting in real time to evade security barriers. For example, it may disable certain defences while masking its activities to appear as normal system behaviour. Alternatively, as more companies implement AI agents – advanced chatbots, more threat actors will target them.

Ransomware will evolve significantly in 2025, with attackers introducing more aggressive tactics to maximise pressure on victims. One such method is Triple Extortion, where beyond locking data and threatening its public release, attackers also target a company’s partners, customers, or supply chain to amplify demands. Another emerging tactic is Data Wiping Ransomware, where attackers may abandon monetary demands altogether, opting instead to disable systems or erase data as a form of ideological or geopolitical warfare. These strategies signal a shift towards more destructive and far-reaching impacts in ransomware attacks.

Supply chain compromises will become increasingly favoured by attackers because they allow them to infiltrate networks via trusted third parties. Software vendors, open-source software, cloud services, and hardware suppliers remain particularly vulnerable. By enabling a compromise at source and inserting malicious code into legitimate software updates or manipulating open-source libraries relied on by thousands of organisations, or hardware backdoors, with attackers embedding vulnerabilities into hardware supply chains, attacks will become more challenging to detect and manage over the long term.

As a result, critical infrastructure will face mounting threats as cybercriminals exploit vulnerabilities in supply chains and essential services, often causing widespread disruptions. With the interconnectedness brought about by IoT and edge computing, attacks targeting dispersed data will increase, posing challenges in securing distributed networks.

Blindspots and Weaknesses

Shadow AI

Shadow IT has long exposed organisations to risks through unauthorized software and applications that bypass security protocols. The emergence of shadow AI—unauthorised AI tools used without IT approval—amplifies these vulnerabilities. Research by e2e-assure reveals a significant gap between perception and reality; while 85% of cyber risk owners express confidence in their AI policies, only 34% of employees are even aware such guidance exists. This disconnect heightens the risk of data breaches, regulatory non-compliance, and weakened security frameworks, creating fertile ground for cyber threats and data mismanagement.

Ethics

The ethical challenges posed by advancing AI technologies will demand urgent attention in 2025. These challenges include bias and discrimination embedded in algorithms, privacy violations due to enhanced surveillance capabilities, and the difficulty of assigning accountability for decisions made by AI systems.

Addressing these issues requires the active involvement of all stakeholders—governments, organisations, technologists, and the public—to build ethical frameworks that strike a balance between safeguarding public interests and fostering innovation. Transparency must be a foundational pillar in AI development, ensuring that systems are explainable and free from hidden biases. Inclusivity is equally critical, with diverse perspectives shaping the direction of AI to ensure it reflects the values of a broad society. Continuous evaluation is vital, enabling periodic checks to align AI systems with evolving ethical standards and societal priorities. By taking these steps, we can harness AI’s potential responsibly and equitably for a more secure and ethical future.

Human Factor Vulnerabilities

Human factor vulnerabilities will remain a critical challenge in 2025, even as organizations adopt advanced technologies to fortify their defenses. Cyber threats often exploit human errors, whether through phishing attacks, weak passwords, or lapses in protocol. This reinforces the pressing need for comprehensive training and awareness programs that foster a culture of vigilance and cybersecurity best practices throughout the workforce.

Incident Response Preparedness

Equally important is incident response preparedness; organizations must have robust crisis response plans in place to act swiftly and effectively during security breaches. These plans should include detailed protocols, clear communication channels, and regular drills to ensure readiness. By prioritizing human-centric cybersecurity and bolstering crisis response capability, organizations can enhance their resilience against the evolving threat landscape and minimize potential damage.

CISO Perceptions

A critical blind spot for CISOs and cyber risk owners is the divergence in perceptions of their security stack’s effectiveness between leadership and technical teams. While the majority of the C-suite considers their security stack highly capable, a significant number of ITOps professionals see it differently. This gap indicates a disconnect where executives primarily focus on overarching strategy, whereas ITOps face operational challenges firsthand. Bridging this divide requires stronger communication to align perspectives and ensure a cohesive defense strategy. For a deeper analysis of these disparities, explore the insights shared in the latest ManageEngine report.

Cyber Approaches

To counteract these evolving threats, organisations must pivot from reactive defenses to proactive strategies. AI-powered tools will play a vital role in enabling real-time detection, predictive threat modeling, and responsive threat mitigation. For instance, AI-driven Security Operation Center (SOC) co-pilots will assist in analysing massive data streams, prioritising incidents, and improving efficiency.

Further, organisations will increasingly adopt zero-trust architectures to combat identity-based threats – which have just taken over endpoints as the primary attack vector, focusing on strict identity and access management (IAM) practices, passkeys, and enforcing multi-factor authentication (MFA).

Quantum-resistant cryptography will also emerge as a critical investment as quantum technology poses new risks to conventional encryption standards.

Regulations and Guidance

According to analyst Gartner, 69% of employees have bypassed cyber security guidance in the last 12 months, while 74% said they would be willing to do so if it helped them to achieve a business goal. By 2025, the regulatory landscape is set to undergo significant transformations with the introduction of stricter data protection laws and compliance requirements globally. While regulators understand that perfection is impossible, they are leaning into a global trend and revising expectations for cybersecurity. They want to see organisations building out and making visible their practices and procedures for how they navigate incidents, as well as anticipating and preparing for new ones. This evolving framework pushes businesses to prioritise robust cybersecurity measures that align with both operational needs and regulatory demands.

Key developments include:

1. USA: The return of the Trump administration heralds a likely shift toward deregulation in U.S. cybersecurity policies by 2025. This approach, focused on reducing federal oversight, brings significant implications for federal and state-level laws, alongside how businesses manage compliance and maintain cybersecurity standards.
   
   
2. The future of the American Privacy Rights Act (APRA), proposed as a federal framework to unify data privacy standards, is now uncertain. The administration’s preference for minimising regulations may stall or revise the act, likely scaling back its focus on consumer rights and stringent compliance requirements. This could leave businesses navigating a fragmented landscape with varying state-level laws instead of a consistent federal standard. While federal advances may slow, state-level momentum continues. States like New Jersey, Tennessee, and Minnesota are developing comprehensive data privacy laws that emphasise data transparency, risk assessments, and consumer protection. However, these efforts could clash with federal priorities for streamlined regulations. Businesses may face differing compliance expectations depending on the states they operate in, adding complexity to nationwide operations. A key feature of the administration’s policy is likely deregulation, targeting existing cybersecurity mandates to reduce compliance burdens on businesses. This could mean relaxed reporting deadlines, fewer audit requirements, and greater flexibility for organizations, particularly benefiting small-to-medium enterprises. Yet, a lighter regulatory touch could also weaken baseline cybersecurity standards, increasing the risk of breaches and inconsistent protections across industries.
   
   
3. Europe: The EU continues to refine its data protection framework with the introduction of the Data Act and the Cyber Resilience Act, focusing on cybersecurity and data management. The EU is also enhancing regulations around AI and children’s privacy. Additionally, financial organisations and third party tech providers will be expected to be fully compliant to the Digital Operational Resilience Act (DORA) by January 2025.
   
   
4. Asia: Countries like Vietnam, Malaysia, and Indonesia are updating their data protection laws. These include mandatory breach notifications, appointment of Data Protection Officers (DPOs), and enhanced penalties for non-compliance.
   
   
5. Middle East: Middle Eastern countries are actively enhancing their cybersecurity frameworks in anticipation of 2025. Key developments include:
   
   
6. Saudi Arabia’s Advanced Cyber Frameworks The Kingdom’s Communications, Space, and Technology Commission (CSTC) has introduced stringent regulations targeting service providers in the IT, communications, and postal sectors. These policies emphasise consumer data protection, network security, and incident reporting. Companies must adopt proactive risk management practices and ensure compliance with the updated standards to avoid penalties.UAE’s Comprehensive Cybersecurity Policies The UAE Cybersecurity Council is spearheading new initiatives targeting key areas like cloud computing security, IoT device protections, and cybersecurity operation centers. These frameworks aim to enhance digital trust while promoting technological innovation. Businesses will need to secure their data storage systems, safeguard interconnected devices, and demonstrate readiness to counter evolving cyber threats.Broader Regional Efforts Other nations, including Oman, Qatar, and Jordan, are actively updating their cybersecurity regulations. These frameworks focus on strengthening legal obligations for organizations handling sensitive data. Requirements include mandatory breach reporting, adherence to cross-border data transfer restrictions, and appointing Data Protection Officers (DPOs) to oversee compliance.IoT and Cloud Computing Priorities With the Middle East adopting IoT devices and cloud solutions at a rapid pace, governments are formulating specific policies to address the associated risks. Regulations will require device manufacturers and cloud providers to uphold security-by-design principles, ensuring that potential vulnerabilities are mitigated during the development stage.
   
   
7. Africa: Nations are developing data protection laws, with some like Nigeria and Tanzania already implementing new regulations. The Malabo Convention aims to harmonize data protection laws across the African Union.

Fines and Class-action Law Suits

Historically, regulations have struggled to keep pace with the swift evolution of cybercriminal tactics, creating vulnerabilities for both customers and employees. This gap has fuelled a surge in class-action lawsuits, now reaching a 13-year peak, as affected parties seek compensation for breach-related damages. Looking ahead to 2025, the incidence of such lawsuits is anticipated to become a more pressing issue for businesses. This trend is driven by the increasing sophistication of cyber threats, which heightens the risk of breaches and subsequent legal challenges.

As consumers and employees become more informed about their rights and the possibility of legal recourse, the propensity to pursue class-action lawsuits grows. If regulatory measures fail to match the threat landscape, individuals are more likely to turn to the courts for justice, further amplifying this trend.

The financial impact of these lawsuits is considerable, compelling companies to prioritise investments in cybersecurity and strengthen their legal defences. Additionally, as legal precedents and frameworks develop through ongoing litigation, the path to successful lawsuits becomes more accessible. Consequently, businesses must proactively enhance their cybersecurity strategies and legal preparedness to reduce the risks and financial burdens associated with potential class-action suits.

Cyber Insurance

Cyber insurance will become an essential component of risk management strategies. As cyber threats become more prevalent, insurance providers will refine their offerings to cover a broader range of incidents. However, businesses must carefully assess their coverage to ensure it aligns with their specific risk profiles and potential exposures.

Regulators will also emphasise the importance of cybersecurity audits and assessments, requiring organisations to demonstrate their commitment to securing customer data and maintaining robust defenses. This increased scrutiny will drive improvements in cybersecurity practices across industries, fostering a culture of accountability and vigilance.

Insurance for CISOs and IT leaders will also become critical, not only as a key component of risk management strategies but also as a safeguard against personal liability. While Directors’ and officers’ (D&O) insurance liability exists, new professional liability insurance offerings tailored for CISOs, plus a cybersecurity trade union, care of The Security Industry Federation (SIF), will enable leaders to better protect themselves from personal financial losses arising from lawsuits tied to breaches or security incidents.

This type of coverage offers a vital layer of security, allowing CISOs to focus on lowering cyber risks without the added fear of personal repercussions. Those who leverage such insurance strategically will also be able to demonstrate a proactive stance on cybersecurity, which can significantly enhance their market reputation. By reducing potential damages and showing commitment to safeguarding both data and leadership, organisations will be able to build greater customer trust and loyalty, setting themselves apart in an increasingly security-conscious world.

Useful resources include:

• The Professional Association of CISOs at https://theciso.org/membership/.
• SIF at https://sif.org.uk/
• Cyber Future Foundation at https://cyberfuturefoundation.org

Workforce

The cybersecurity field in 2025 faces a complex interplay of challenges, from a shifting skills gap to intensifying burnout among professionals and the evolving role of the CISO. While some specialised roles continue to face talent shortages, automation and advancing technologies are leading to redundancies in others. To succeed now, cybersecurity professionals must demonstrate unique, irreplaceable value—offering skills and insights that machines cannot replicate. Adaptability has become paramount, with an emphasis on possessing the right skills to manage emerging threats and complex regulations in a rapidly evolving landscape.

These pressures are particularly acute for CISOs, whose roles are transitioning into broader integrated risk management positions, increasingly overlapping with the responsibilities of Chief Information Officers (CIOs). This convergence requires CISOs to go beyond traditional security practices and prove their business value. Failure to do so could render them redundant, prompting many to consider transitioning into roles as virtual CISOs (vCISOs) or CSO consultants to balance escalating responsibilities and accountability.

The burden on CISOs is immense, encapsulated by SolarWinds CISO Tim Brown’s remark, “We’ve been hearing CISO is the ‘chief scapegoat officer,’ right?” This sentiment underscores the growing scrutiny on these professionals, worsened by high-profile cases, such as the U.S. Securities and Exchange Commission’s lawsuit against SolarWinds and Uber, which spotlight the personal risks involved.

Meanwhile, across the broader cybersecurity landscape, burnout is becoming a critical concern as security teams grapple with relentless workloads and the emotional strain of high-stakes responsibilities. AI-driven tools are poised to ease these burdens by automating routine tasks, streamlining incident responses, and reducing false positives, offering professionals much-needed relief. However, technology alone is not enough. Organisations must prioritise work-life balance, providing mental health resources, and creating supportive, collaborative work environments to retain talent and maintain resilience. For CISOs and cybersecurity experts alike, aligning security with broader business objectives and investing in holistic well-being strategies will be essential to thriving in the high-pressure years ahead.

Growth Markets

The cybersecurity global skills shortage is a major factor driving investment in the security services market (security consulting services, security professional services and managed security services) which is expected to grow faster than the other security segments in 2025.

The rising sophistication of cyberattacks has heightened the demand for AI-powered threat detection and automated incident response solutions with research showing that companies leveraging these tools to prevent data breaches save an average of $2.22 million annually compared to those that don’t.

Similarly, as businesses continue their migration to cloud environments, robust cloud security solutions are becoming essential to protect sensitive data and workloads. With the proliferation of IoT devices across industries like healthcare, manufacturing, and smart cities, IoT security is also emerging as a critical area, designed to safeguard vast networks of connected devices from vulnerabilities.

Certain industries and markets are expected to drive cybersecurity innovation through 2025. These include healthcare, where safeguarding patient data against attacks like ransomware will remain critical, and finance, where protecting against state-sponsored intrusions and fraud becomes paramount.

Emerging markets like green technology and electric grids will also demand robust protections as they become key targets due to their essential role in addressing global energy needs. Furthermore, small-to-medium-sized businesses, often part of supply chains, will likely invest more in affordable, scalable cybersecurity solutions as they become increasingly targeted. Some analysts are predicting a focused market move from large USA enterprises to Europe SMEs.

The Road Ahead

The cybersecurity landscape of 2025 will be shaped by the convergence of challenges and opportunities. Organisations and their leaders must prioritise resilience through robust identity protection, proactive approaches leveraging AI, adherence to evolving regulations, and investment in workforce development. Collaboration, innovation, and foresight will be essential for surviving and thriving in this rapidly shifting environment. Businesses that adapt to and anticipate these changes will not only mitigate risk but position themselves as leaders in the new era of cybersecurity.

Now I want to hear from you…

Tell me where you see the market going next year? What am I missing. Join in the conversation on LinkedIn, here.

By Jane Frankland (Business Owner & CEO, KnewStart)

Original link of post is here

Welcome to the Challenge: Governance, Risk & Security

A CISO’s world is never just about technology. It’s about governance, risk, and control. Without governance, security becomes a guessing game. Without risk management, threats remain unseen. A 30-60-90 day plan is the key to balancing it all. Let’s dive in.

First 30 Days: Establishing Governance & Understanding Risk

1. Governance: The Foundation of Security

A lack of governance is a risk in itself.

• Start at the top. Board members and senior executives set the tone.
• Establish an advisory committee. Business leaders need a say in security.
• Define security’s role in IT strategy. If IT moves, security moves with it.

2. Prioritize Risk Management

Security is about controlling risk, not eliminating it.

• Identify risk appetite. What’s an acceptable loss? Ask the CFO.
• Use a framework. NIST, ISO, COBIT—pick one and stick to it.
• Map risks to business impact. Not all threats need the same response.

3. Streamline Security Requests

Security must move at business speed.

• Fix firewall bottlenecks. If IT controls the firewall, ensure security has a say.
• Prioritize security projects. Delayed security is a vulnerability.
• Understand approval processes. Know how to get projects funded and prioritized.

By the end of this phase, governance should be defined, risk appetite clear, and security positioned as a business enabler.

Day 31-60: Implementing Controls & Enhancing Visibility

4. Define & Enforce Security Frameworks

Frameworks provide structure and accountability.

• Choose a primary framework. NIST, ISO, or COBIT are common choices.
• Standardize policies. Align controls with business operations.
• Ensure compliance integration. Security must fit into audit, legal, and regulatory needs.

5. Validate Security Tools & Justify Technology

Security tools should serve a purpose—not just exist.

• Review existing technology. Every 18 months, ask, “Is this still the best option?”
• Evaluate alternatives. Challenge vendors to stay competitive.
• Automate where possible. AI and analytics can reduce manual workload.

6. Align Training with Business Needs

Security teams must keep up with evolving threats.

• Mandate training. Five days of training per person every 90 days.
• Encourage cross-training. No single points of failure.
• Invest in certifications. Cloud, risk, and compliance skills are critical.

By the end of this phase, security controls should be aligned with business needs, tools should be justified, and staff should be continuously improving.

Day 61-90: Maturity, Automation & Continuous Improvement

7. Governance Committees: Keep Security in the Loop

Security decisions need leadership buy-in.

• Join audit and risk committees. Security must be part of corporate governance.
• Engage in IT strategy discussions. Security can’t be an afterthought.
• Ensure compliance reporting is proactive. Don’t wait for audits to find gaps.

8. Continuous Security Improvement

Security isn’t static. It evolves.

• Schedule vulnerability scans daily. Don’t wait for a breach to find weaknesses.
• Monitor technology roadmaps. Know when your tools are becoming obsolete.
• Refine security metrics. Measure effectiveness, not just activity.

9. Secure the Development Lifecycle

Code security matters just as much as network security.

• Implement code reviews. Security should be part of development, not an afterthought.
• Use automated security testing. Catch vulnerabilities early.
• Adopt secure coding standards. Reduce risk before deployment.

By the end of 90 days, governance should be strong, risk should be managed, and security should be woven into business operations.

The Future: Staying Ahead of Threats

Cybersecurity doesn’t stop at 90 days. It’s an ongoing cycle.

• Monitor, refine, repeat. Governance and security must adapt to business changes.
• Justify security investments. Keep proving the value of security initiatives.
• Train relentlessly. Technology evolves fast—your team must evolve faster.

With a structured 30-60-90 day plan, CISOs can build a security function that’s resilient, responsive, and ready for anything. Now, go secure the enterprise.

Join CISO Platform — the CyberSecurity Community
Gain exclusive insights from top security professionals and access cutting-edge research.
Join Now

By: Gordon Rudd (Cheif Executive Officer, Stone Creek Coaching)

After a long, long, long writing effort … eh … break, we are ready with our 5th Deloitte and Google Cloud Future of the SOC paper “Future of SOC: Transform the ‘How’.”

As a reminder (and I promise you do need it; it has been years…), the previous 4 papers are:

• “New Paper: “Future of the SOC: Evolution or Optimization — Choose Your Path” (Paper 4 of 4.5)” [please consider rereading this before reading the new one!]
• “New Paper: “Future Of The SOC: Process Consistency and Creativity: a Delicate Balance” (Paper 3 of 4)”
• “New Paper: “Future of the SOC: SOC People — Skills, Not Tiers” (Paper 2 of 4)”
• “New Paper: “Future of the SOC: Forces shaping modern security operations” (Paper 1 of 4)”

When facing the question of whether to evolve or optimize a Security Operations Center (SOC), security leaders have numerous risks and rewards to consider. Disruptions to normal operations, migration challenges, compatibility issues, advantages of new technologies, and learning curves for the teams involved are many important factors to consider.

Previously in our “Future of the SOC” series, we explored the conditions in which security leaders could transform SOC tools and practices vs conditions in which leaders could double down and improve their existing tooling and ways. Specifically, in our “Future of the SOC: Evolution or Optimization — Choose Your Path,” we laid out a decision matrix to help navigate the decision on whether to change or stay.

However, when we wrote the previous paper, lots of people asked us: OK, we ran through the process and the process led us to the need to transform (rather than optimize) our SOC. How do we go about it? Are there boosters or amplifiers for this? Are there related projects you can latch on, as this whole transformation business is just hard? This is exactly what we cover here in our current paper.

Specifically, we explore the change decision tree through the lens of three common scenarios as drivers for transformation: Cloud migration, Managed Detection and Response (MDR) adoption, and DevOps evolution.

My favorite quotes:

• “As organizations migrate to the cloud, there’s a notable shift from endpoint-centric security models to a broader focus on data correlation and aggregation facilitated by SIEM and SOAR technologies. This shift is crucial for adapting to the dynamic, distributed nature of cloud environments and for effectively managing the increased complexity and profusion of security data. ” [A.C. — in less polite terms, “EDR-huggers” need to either push their EDR vendors to do real, not-endpoint-centric Cloud D&R or stop hugging…]
  
  
• ‘Shadow operations teams: Observe the incumbent service providers’ operations teams and/or the Customer Operations team in their day-to-day activities to understand and document lessons learned, known issues, exception scenarios, priorities, and dependencies” [A.C. — in this MDR-centric transformation the point is actually … getting better by learning from them, not doing the “four letter o” word … “outsourcing” :-) ]
  
  
• “The main challenge is that when the IT counterpart to security is much faster (hours vs. months, in some cases), security needs to “speed up or shut up.” Agile IT with 1990s-style slow security will fight, and the modern approach (IT) will normally win… putting the organization at risk.” [A.C. — never bet against inertia in large enterprise IT!]
  
  
• “A modern SOC should be an integral part of the DevOps ecosystem. It should prioritize speed, automation, and a mindset that treats security as an essential component of the development process from the outset. ” [A.C. — this sounds cliche, but security should not fight DevOps, but learn and adopt from it]

The paper is full of gems that go far beyond these quotes. Go and read it, but do consider rereading the previous paper before doing to.

Related blog posts:

• “New Paper: “Future of the SOC: Evolution or Optimization — Choose Your Path” (Paper 4 of 4.5)”
• Video version of this (slides)
• “New Paper: “Future Of The SOC: Process Consistency and Creativity: a Delicate Balance” (Paper 3 of 4)”
• “New Paper: “Future of the SOC: Forces shaping modern security operations””
• “New Paper: “Future of the SOC: SOC People — Skills, Not Tiers””
• “New Paper: “Autonomic Security Operations — 10X Transformation of the Security Operations Center”
• WTH is Modern SOC, Part 1
• Baby ASO: A Minimal Viable Transformation for Your SOC
• Original ASO paper (2021)

- By Anton Chuvakin (Ex-Gartner VP Research; Head Security Google Cloud)

Original link of post is here

My former “colleagues” have written several serious pieces of research about why a SOC without humans will never happen (“Predict 2025: There Will Never Be an Autonomous SOC”, “The “Autonomous SOC” Is A Pipe Dream”, “Stop Trying To Take Humans Out Of Security Operations”). But I wanted to write a funny companion to this called “How to Talk to Idiots Who Believe in ‘Humanless SOC’.” Here it is, but it is definitely a rant and not technical guidance, mind you.

I think most of us will encounter people who believe that a Security Operations Center (SOC) fully staffed by machines and with no humans anywhere will actually happen. Now, I think those people are delusional, but it is interesting to try to study those delusions. Try to psychoanalyze them, perhaps. Maybe this points to some suppressed childhood trauma, I dunno…

Years ago, I had an old and wise mentor who explained everything weird in the (human) universe by a unique (for each occurrence) blend of two forces: corruption and stupidity. Perhaps this can be applied here? Some may believe this out of ignorance (see more on this below) while others choose to believe it because their VC funding depends on it…

Anyhow, let’s look at the extreme fringe of a fringe. You may meet people who think that artificial intelligence today is so advanced that human presence inside the SOC is not necessary. Today! They actually think AI can already replace all humans in a SOC! Some of them even have a demo ready, powered by … ahem … “a demo-ready AI” that works — you guessed it! — in a demo. Sadly, it will never deliver even a tiny fraction of the promised benefits once confronted with a real-world, messy environments full of outdated systems, API-less data stores, tribal knowledge, junior IT people, and sprinkled with human incompetence…

Similarly, some people have never seen how a large enterprise functions, so they make assumptions about automation possibilities that are just wildly off. They struggle to grasp the complexity of a “typical” (ha! as if!) enterprise “layered cake” environment, with its layers of technology ranging from 1970s mainframes to modern serverless and gen AI systems.

To elaborate on the lack of enterprise environment knowledge, what makes it even worse is common reliance on tribal knowledge of unique systems — knowledge that only exists in the minds of specific individuals. It’s very difficult, if not impossible, for any automated system (whether AI-powered or not) to make decisions based on context that simply isn’t present in computers…

In other cases, an utter lack of understanding of how modern (and especially not-so-modern) security operations centers, and detection and response teams operate comes up. Some snakeoil sellers of “humanless SOC’” rely on things like ”this needs a current asset list, we will just query CMDB or Attack Surface Manager.” Ah, a CMDB that was last updated in 2008, and an ASM that covers a third of the environment … suuure. They often promise (or, worse: ask the customer to!) to “fix these issues before deployment,” failing to acknowledge that some of these issues have persisted for decades. “Decades, Karl!” That’s like 10+ years! :-)

Yet another category of people believe in a humanless SOC based on their complete lack of understanding of threats. In fact, they shift their AI so far right (“AI SOC = better alert triage”), and neglect bad detection content altogether… And, yes, threat actors sometimes know the environment better than the defenders do. I’m optimistic that in the long term, with the wider adoption of cloud computing, the occasional attacker advantage will vanish. Defenders will collect more data on their environments and be able to keep it updated (well, I can hope, can I?) Today, however, it is just not the case.

Now, what about trying to match the quality of a bad SOC, like one run by a low-end MSSP vendor? As I alluded before, artificial intelligence today seems close to matching the quality of a bad SOC without any humans. To this, I add: If you lower the bar enough, you can match the quality of a bad SOC even without AI. Just connect your SIEM alerts to an alert distribution mechanism like email. Done! You have a really, really, really, really bad SOC, and without any humans. And without AI too!

So using this argument (“I can replicate a really bad SOC with AI”) is essentially cheating (more seriously, if one can replicate a “mediocre+” MDR but without any human “butts in seats”, this can be a decent business!)

Finally, there is one delusion that’s actually worthy of deeper analysis: the belief that AI will soon advance so rapidly and so massively that it will replace all humans in the SOC. Let’s not turn this into “are LLM a path to AGI?”; actual AI experts can debate this one. We will focus on the SOC.

Let’s start this discussion with good news. Several years ago (2021), I was a long-term optimist, but a short-term skeptic about AI in security. Now, I’m even more optimistic in the long term and cautiously optimistic in the short term. Despite my optimism, I don’t see a short-to-medium-term trajectory for AI that would lead to a humanless SOC. I do see a lot of AI use in the SOC, to be sure, but a SOC run by humans!

Notably, when we developed Autonomic Security Operations (ASO), we stressed that humans are central to modern security operations (as they are with our own D&R capabilities). We also mentioned the many tools used in such operations, including of course AI.

Where can you go from here? We can discuss what’s possible, and increased automation of your security operations center is definitely on that list. We can also explore the potential pathways that might eventually (EVENTUALLT!) lead to a humanless SOC. However, this is the world of tomorrow…

… and we are back to today!

Here are my Top Reasons Why a SOC Without Humans Will Not Happen:

1. Tribal Knowledge: Crucial knowledge for alert triage, investigation and detection authoring often exists only in someone’s head, not in any automated or even any digital system (you gen AI “agent” may read the pages of an analog notebook, to be sure, but a human is needed to shove said notebook in front of a robot’s all-seeing-eye…)
2. Adaptable Attackers: Creative attackers will continue to outsmart automated (including gen AI — powered) defenses, as they possess the ingenuity and adaptability that machines currently lack (this argument very much applies to short-to-medium term and I make no promises for long term, mind you, AGI FTW … but LATER!)
3. Security Data Quality: Many AI projects are limited by the quality of their data. Building an excellent “AI SOC” requires vast amounts of high-quality data, which is often unavailable, and this is doubly so for company-specific data (we can debate how attack-surface-agnostic you can make this in later blogs…)

These are just a few of the main reasons why a fully automated (humanless, fully autonomous, etc) SOC is not feasible in the near future. If you encounter someone who believes in this fallacy, remind them of the importance of tribal knowledge, expert intuition, attacker adaptability, and the limitations of current AI technology due to insufficient data quality. These challenges remain largely insurmountable, even with projected technological advancements.

Finally…

A critical challenge in writing this blog is my unwavering belief in the relentless pursuit of automation within a detection and response domain. Ideas like ASO (and its origins) have demonstrated that an engineering mentality and a drive to automate more activities are crucial for building a modern SOC. In fact, SRE’s job is to “automate yourself out of your job”, but here lies a paradox: humans are needed to automate humans out of a human job, yet this loop is endless…

Related posts:

• Baby ASO: A Minimal Viable Transformation for Your SOC
• Anton’s Alert Fatigue: The Study
• New Paper: “Future of SOC: Transform the ‘How’” (Paper 5)

- By Anton Chuvakin (Ex-Gartner VP Research; Head Security Google Cloud)

Original link of post is here

This is my completely informal, uncertified, unreviewed and otherwise completely unofficial blog inspired by my reading of our next Threat Horizons Report, #11 (full version) that we just released (the official blog for #1 report, my unofficial blogs for #2, #3, #4, #5, #6, #7, #8, #9 and #10).

My favorite quotes from the report follow below:

• “Nearly half (46.4%) of the observed security alerts were due to overprivileged service accounts. ” [A.C. — using new data on cloud detections, we confirmed an old hypothesis: if you overprovision, you suffer. Very cause->effect: overprovision -> suffer!]

• “During H2 2024, credential-related vulnerabilities like weak or no passwords continued to be the most common entry point for attackers as shown [below], though the frequency decreased slightly through 2024. Misconfiguration of cloud environments (services or software) remained a significant security gap.” [A.C. As I said in other THR blogs, the main news here is that there is no news; a lot of cloud security problems in 2025 are 2020 problems, at best. Initial access vectors didn’t change all that much. “Secure by default” seems to apply to new cloud deployments perhaps and having no effect on what is running today …]
• “We also observed a new trend in the second half of 2024: a sharp rise in compromised APIs and UIs due to threat actor targeting. These attacks accounted for 17.1% of observed incidents, a substantial increase from the approximately 13% observed in the first half of 2024. “ [A.C. — aha, something DOES change! Perhaps all that endless whining of those ‘“API security vendors” had an effect and attackers are finally interested :-)]

• “We also saw a significant trend in threat actors searching for insecure private keys (13.7%), reinforcing the need for organizations to prioritize the security and proper management of private keys.” [A.C. — next time, somebody asks you in the dark cloud alley “do you even lateral, dude?”, you go “PRIVATE KEY SEARCH!!!”]
• “More than half (62.2%) of threat actor movements once they gained access involved attempting lateral movement within an environment and downloading tools designed for this purpose.” [A.C. — not sure what happened to cryptomining, I think we fixed it…]

• “Identity compromise is no longer limited to password theft based upon misconfigurations or weak passwords. Threat actors are now gaining access by intercepting or stealing post-authenticated tokens or cookies, effectively bypassing traditional authentication criteria. ” [A.C. — while I am still not a fan of ITDR as a separate tool, it is very clear that we are still under-equipped to fight this one…]
• “The most common methods of identity compromise include brute-forcing using common/guessable passwords, replaying stolen credentials from a previous breach, credential stuffing, phishing, and social engineering.” [A.C. — in other words, a range of 1970s-2020s tactics and methods ;-) And, yes, well-crafted MFA helps against many of these, but not all]
• “Threat actors are increasingly targeting identities and databases, exploiting misconfigurations and vulnerabilities to gain access to sensitive information and resources. Insecure databases containing critical business data and personally identifiable information (PII) are particularly attractive targets.” [A.C. — I am going to channel Captain Obvious here, but can you imagine? Corporate databases contain valuable data! No way, right? And somebody will steal it if you don’t secure it….]
• “To take over cloud service accounts, TRIPLESTRENGTH leverages stolen credentials and cookies, at least a portion of which have come from Racoon infostealer logs, to gain access to victim cloud environments.” [A.C. — a fun example re: cookies!]
• “Mandiant has observed threat actors increasingly extorting victim organizations by exposing their stolen data on Data Leak Sites (DLS). […] The expanded use of these extortion tactics combined with the prevalence of DLS poses a growing threat for all organizations, regardless of where their data is stored.” [A.C. — kinda makes sense, I suspect [gut, not data!] that “encrypt only” was easier on-prem, whole “encrypt+steal and post” works in the cloud]

Now, go and read the THR 11 report!

P.S. Coming soon! Trend analysis of THR1–11!

Related posts:

• EP112 Threat Horizons — How Google Does Threat Intelligence podcast
• Google Cloud Security Threat Horizons Report #10 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #9 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #8 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #7 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #6 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #5 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #4 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #3 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #2 Is Out!
• Illicit coin mining, ransomware, APTs target cloud users in first Google
• Cybersecurity Action Team Threat Horizons report

- By Anton Chuvakin (Ex-Gartner VP Research; Head Security Google Cloud)

Original link of post is here

Imagine walking into a crowded airport where security checks every bag. Some bags trigger an alert and are flagged. Security pauses and asks: “Is this dangerous or just an innocent traveler carrying metal in their pockets?” Now, picture this in the digital world. Every web request is like a passenger, and anomaly scoring in ModSecurity Core Rule Set (CRS) is the sharp-eyed security guard deciding what goes through and what gets stopped.

What Is Anomaly Scoring?

Most Web Application Firewalls (WAFs) act like traffic lights. They give a simple go or stop. Good traffic passes, and bad traffic gets blocked. But anomaly scoring changes the game. Instead of saying “block” or “allow” based on one rule, it looks at everything happening.

• Every detection rule adds a score.
  
  
• Higher scores mean more suspicious activity.
  
  
• Once the score crosses a threshold, action is taken.
  
  

Why This Matters

Blocking or allowing traffic based on one event is risky. False positives pile up. The system gets overwhelmed. The result? Legitimate requests get flagged, and attackers sneak through. Anomaly scoring adds layers. It looks at multiple signals before deciding. This makes it easier to manage false positives while keeping the bad guys out.

Breaking Down the Anomaly Scoring Process

Here’s how it unfolds:

1. Detection Before Blocking

Anomaly scoring separates detection from blocking. It gives time to analyze before stopping traffic. Hundreds of rules inspect requests and assign scores.

• SQL injections? +5 points.
  
  
• XSS attempts? Another +5.
  
  
• More hits? The score goes up.
  
  

2. Threshold Control

Each request starts at zero. As suspicious activity is detected, the score builds. Once it crosses a defined threshold (let’s say 15), ModSecurity decides whether to block or allow it.

• Below threshold: Pass.
  
  
• Above threshold: Block.
  
  

The False Positive Problem

Here’s where things get tricky. When moving to production, many choose to start in monitoring mode. It’s like watching traffic but not stopping anything. This helps catch false positives. But when those pile up? It’s overwhelming. Imagine sorting through 100,000 alerts just to figure out what's real.

Anomaly scoring solves this. It lets security teams refine and fine-tune thresholds without blocking legitimate traffic.

A Smarter Way to Fine-Tune Security

1. Start High, Lower Gradually

Think of anomaly scoring like adjusting the volume on a speaker. You don’t start with it blaring at full blast.

• Day 1: Start at a very high threshold—say 10,000.
  
  
• Slowly reduce it over time, perhaps to 100.
  
  
• Each step reveals patterns and reduces false positives.
  
  

2. Iterative Tuning

With every iteration, it’s easier to see the troublemakers. Fine-tuning means looking at requests scoring 100 or higher, analyzing what triggered them, and adjusting accordingly.

3. Reduce Thresholds in Phases

Drop the threshold step by step:

• From 10,000 to 100.
  
  
• From 100 to 50.
  
  
• Gradually, down to 5.
  
  

At 20, real security kicks in. Real attacks get blocked while false positives drop.

The Power of Small Wins

Every time the threshold drops, more false positives disappear. By focusing on the highest-scoring requests, the team clears the noise.

• 80% of false positives get handled in the first iteration.
  
  
• By the time the threshold hits 20, critical attacks are blocked.
  
  

Trust Through Iteration

Anomaly scoring isn’t just about blocking attacks. It’s about building confidence in your system. Step by step, thresholds lower, but the system stays stable. Nobody calls the helpdesk screaming about broken forms or blocked registrations.

• Iteration 1: Big wins.
  
  
• Iteration 2: Sharper controls.
  
  
• Iteration 3: Real security with fewer false alarms.
  
  

Why Anomaly Scoring Is a Game-Changer

1. Flexibility in Production

You’re not guessing. The system learns as it goes. Traffic is analyzed, refined, and adjusted to protect real users without breaking functionality.

2. Lower Risk, Higher Accuracy

False positives go down. Real attacks get caught. Everyone wins.

3. Human-Centric Approach

Instead of relying solely on machines, anomaly scoring empowers security teams to fine-tune and iterate over time.

Getting to the Finish Line

The goal? A crisp, sharp system where one bad request triggers a block. The path to get there isn’t immediate but careful and measured. It takes about 4-6 iterations before reaching this optimal state.

• Confidence grows with every phase.
  
  
• False positives shrink.
  
  
• The system becomes an invisible shield, protecting without interfering.
  
  

Final Thoughts

Anomaly scoring is not magic. It’s a well-defined, practical approach to securing web applications. By analyzing requests, assigning scores, and adjusting thresholds gradually, organizations gain better protection without upsetting users.

So, next time you think about web application security, remember: it’s not just about stopping the bad. It’s about learning, adjusting, and growing stronger—just like anomaly scoring does, step by step.

Join CISO Platform — the CyberSecurity Community
Gain exclusive insights from top security professionals and access cutting-edge research.
Join Now

By: Christian Folini (Teacher and Security Engineer, Partner, Netnea.com)

Imagine walking down a busy street where pickpockets are lurking. You wouldn't flash your wallet, right? Instead, you'd zip it away, staying one step ahead. That's exactly what the OWASP ModSecurity Core Rule Set (CRS) does for your web applications—silently shielding them from opportunistic attacks before they can strike.

What is OWASP and Why Should You Care?

OWASP (Open Web Application Security Project) is like the neighborhood watch for web applications. You’ve likely heard of their famous OWASP Top 10—a list of the most common security risks plaguing web apps. But OWASP is much more than that. Among its flagship projects, one stands out as a silent guardian—ModSecurity CRS.

CRS is a set of security rules that works like an intelligent shield. It's not the silver bullet, but it does the heavy lifting. CRS blocks common exploits so that you can focus on the bigger threats that really demand your attention.

Why ModSecurity CRS Matters

Picture a burglar trying different locks to break into a house. CRS makes sure those locks are too tough to crack. It works by blocking attacks before they even touch your application. This is what security pros call “security in depth.”

CRS in Action:

• Stops generic exploits before they reach the application.
  
  
• Hides application weaknesses from casual attackers.
  
  
• Protects against SQL injections, XSS, and other dangerous exploits.
  
  

CRS protects over 100 terabits of traffic per second globally. That’s a lot of bad traffic being kept at bay.

CRS 3: Reviving and Simplifying Security

CRS has been around for nearly 15 years. But let’s be honest—earlier versions weren’t exactly user-friendly. Documentation was sparse, guides were missing, and running it felt like piloting a spaceship without training.

When CRS 3 launched, everything changed.

What’s New in CRS 3?

• Better Documentation: Clearer tutorials, improved integration guides.
  
  
• Easier Setup: A five-minute installation that gets you started quickly.
  
  
• Fewer False Alarms: False positives were reduced by over 95%.
  
  
• Drupal Compatibility: CRS 3 works seamlessly with platforms like Drupal and others.
  
  

How CRS Protects You: Blocking 80% of Known Vulnerabilities

You wouldn’t trust a door lock that fails half the time. CRS doesn't disappoint. Research conducted at the Surik University for Applied Sciences proved this. A security researcher tested CRS with Burp Suite—a tool loaded with aggressive plugins designed to identify vulnerabilities.

The Results?

• Burp fired 4.5 million requests at a vulnerable application.
  
  
• It discovered over 1,000 weaknesses.
  
  
• With CRS 3 in place, 80% of those weaknesses were rendered useless.
  
  

Let’s break it down:

•  SQL Injection: 100% blocked.
  
  
•  Local File Inclusions: Completely neutralized.
  
  
•  Cross-Site Scripting (XSS): Reduced by over 80%.
  
  

Paranoia Levels: Customizing Security for Your Needs

Security is never one-size-fits-all. That's where Paranoia Levels come in. Think of it like adjusting the sensitivity of a car alarm.

• Paranoia Level 1 (PL1): Default and least intrusive. Minimal false positives.
  
  
• Paranoia Level 2 (PL2): Stricter rules, detecting more attacks. Occasional false positives.
  
  
• Paranoia Level 3 (PL3): High alert. Excellent at catching subtle attacks but prone to false positives.
  
  
• Paranoia Level 4 (PL4): Maximum sensitivity. Great for advanced threat detection, but with higher performance costs.
  
  

Each level adds layers of protection. Higher paranoia levels enable more rules, detecting advanced threats but may occasionally mistake friendly requests for attacks.

False Positives: Keeping It Real

False positives are like your smoke alarm going off when you’re cooking dinner. Annoying, but better than a real fire. CRS minimizes false positives by fine-tuning its rule set. And if one slips through? Rule exclusions let you tweak CRS to ignore specific requests that trigger false alarms.

Strongest Areas of Protection

CRS excels in several key areas. Some of its best tricks include:

• SQL Injection (SQLi): Completely neutralized.
  
  
• Local File Inclusion (LFI): Blocks attempts to access sensitive files.
  
  
•  Cross-Site Scripting (XSS): Catches over 80% of attacks.
  
  
•  Remote Command Execution (RCE): Safeguards against command injections.
  
  

Where CRS Could Be Better

No tool is perfect. Redirect attacks and remote file inclusions (RFI) are harder to block. These types of attacks often involve redirecting users to malicious sites. Since there are countless malicious domains, CRS can’t possibly track them all.

To defend against these threats, allow lists are your best friend. Defining which hostnames are acceptable helps block unwanted redirects.

Advanced Threats? Meet Paranoia Level 3 and Beyond

For organizations facing targeted attacks, Paranoia Level 3 (PL3) and Paranoia Level 4 (PL4) are the go-to choices. These levels offer enhanced detection of advanced threats, but with a tradeoff—higher false positives and increased performance costs.

• PL3: Adds specialized rules for complex threats.
  
  
• PL4: Leaves no stone unturned but requires extra vigilance to manage false positives.
  
  

CRS in the Real World: Blocking Millions of Attacks

Think about the last time you clicked a suspicious link and your browser stopped you. That’s CRS, but working silently in the background. Whether it's a SQL injection, a cross-site scripting attempt, or someone trying to retrieve your server’s password file—CRS has your back.

Why You Need ModSecurity CRS

Cyber threats don’t take days off. Neither should your security. CRS acts as the perfect security guard, ensuring your web applications stay safe from the usual suspects.

What ModSecurity CRS Offers:

•  Quick Installation: Up and running in five minutes.
  
  
•  Minimal False Positives: Weed out 95% of false alarms.
  
  
•  Paranoia Level Flexibility: Choose the right level based on your needs.
  
  
•  Protection Against Core Threats: SQLi, XSS, LFI, and more.
  
  

Final Thoughts: Security That Adapts to You

Web applications are constantly evolving. Attackers are getting smarter. But with OWASP ModSecurity CRS, your defenses evolve too. It doesn’t just protect you—it gives you the freedom to focus on building and growing without constantly looking over your shoulder.

CRS isn't a magic bullet, but it’s pretty close. And in the ever-changing world of cybersecurity, that’s a win worth taking.

Join CISO Platform — the CyberSecurity Community
Gain exclusive insights from top security professionals and access cutting-edge research.
Join Now

By: Christian Folini (Teacher and Security Engineer, Partner, Netnea.com)

What is Mod Security?

Imagine an old mechanical watch. Tiny gears, springs, and screws work together. No fancy AI, no wireless updates—just pure engineering. Mod Security works the same way. It’s not flashy. It doesn’t rely on cloud intelligence or machine learning. It sticks to what it knows—patterns, rules, and a solid decision-making process.

When a web request hits, Mod Security looks at it and asks, “Friend or foe?” If it smells trouble, it blocks the request. If it’s safe, it lets it through. Simple, but powerful.

How Does Mod Security Work?

Think of Mod Security as a detective. It doesn’t guess. It examines HTTP requests against a set of known rules. If something looks suspicious, it takes action.

Unlike modern Web Application Firewalls (WAFs) that connect to the cloud and ask for advice, Mod Security works independently. It makes decisions on its own, based on pre-existing patterns that you can tweak. This gives you full control over what goes in and what stays out.

Embedded in Your Web Server

The name says it all. Mod Security is a mod—a module that lives inside your web server. Traditionally, it was paired with Apache, the trusty workhorse of web servers. It was born out of necessity in 2002, when Ivan Ristic developed the first version. Businesses were growing online, and the need to secure web applications became critical.

Soon after, Mod Security caught on like wildfire. By 2005, the community was buzzing, and in 2007, Trustwave took over its development. Fast forward a decade, and Mod Security was no longer exclusive to Apache. It extended its reach to NGINX and IIS. But it wasn’t a smooth transition.

Mod Security’s Growing Pains

Here’s where things get tricky. Mod Security was originally built for Apache. When it moved to NGINX, things got… weird. To make Mod Security run on NGINX, it had to be “fooled” into thinking it was still running on Apache. It worked, but it wasn’t perfect. It was like fitting a square peg into a round hole.

To fix this, developers created Mod Security 3. It was supposed to be a game-changer. It separated Mod Security from the web server using a thin API connector. But there was a catch—Mod Security 3 works best with NGINX. Apache users were left with a gap, and many features from the older version didn’t make the cut.

Mod Security 2.9 vs. Mod Security 3: The Showdown

When comparing Mod Security 2.9 to 3, it’s like comparing a reliable old car with a flashy new model. Mod Security 3 is modern and sleek but has performance gaps and bugs. It’s still catching up.

• Detection Accuracy: Mod Security 2.9 detects 3-5% more test requests than version 3. This means version 2.9 is still the better choice for tight security.
  
  
• Performance: Apache with Mod Security 2.9 runs faster than NGINX with Mod Security 3. While NGINX is naturally faster, adding Mod Security slows it down more than Apache.
  
  
• Compatibility: Mod Security 3 struggles to work seamlessly with Apache due to the lack of a production-ready connector.
  
  

The Power of Rules: Fine-Tuning Security

Mod Security is only as smart as its rules. Think of it like a set of recipes. You can either use ready-made ones or create your own. Most security experts rely on the OWASP Core Rule Set (CRS)—a free, powerful collection of rules that protect against common threats.

These rules cover:

• SQL Injection
  
  
• Cross-Site Scripting (XSS)
  
  
• File Inclusion Attacks
  
  
• Malicious Payloads
  
  

With Mod Security, you can tweak these rules to match your environment perfectly. It’s like tuning a watch to keep perfect time.

Why Control Matters

Mod Security gives you granular control. You can dig into each request, inspect the tiniest details, and tweak the rules to perfection. While many commercial WAFs wrap Mod Security in fancy interfaces, this often strips away that deep control.

Graphical interfaces look good but limit customization. When you configure Mod Security from the command line, you get full access to its potential.

Mod Security’s Future: What Lies Ahead?

For now, Mod Security 2.9 remains the gold standard for Apache users. But change is coming. Mod Security 3, despite its gaps, is the future. As developers iron out the bugs and close the feature gaps, Mod Security 3 will eventually take over.

Until then, sticking with Mod Security 2.9 is a wise choice. It’s stable, reliable, and battle-tested.

Mod Security and OWASP CRS: A Perfect Match

The real power of Mod Security comes to life when paired with the OWASP Core Rule Set (CRS). This combination offers a solid defense against web application attacks. It’s like having an expert locksmith fine-tune your home security system.

Why Mod Security Still Matters

Even with all the advancements in cloud-based security, Mod Security remains a trusted ally for many organizations. It runs independently, provides fine-grained control, and offers protection against the most common web application attacks.

For security teams that value control and transparency, Mod Security is still the best bet. It’s not about bells and whistles. It’s about solid, dependable security that you can trust.

Final Thoughts

Mod Security may be old school, but sometimes, old school is exactly what you need. It’s reliable, predictable, and puts control back in your hands. For those who want to protect their web applications without relying on the cloud, Mod Security remains the go-to choice.

Like a well-tuned watch, Mod Security quietly does its job—keeping things running smoothly, one request at a time.

Join CISO Platform — the CyberSecurity Community
Gain exclusive insights from top security professionals and access cutting-edge research.
Join Now

By: Christian Folini (Teacher and Security Engineer, Partner, Netnea.com)

Imagine a busy highway. Cars zoom past, carrying everything from passengers to valuable goods. But not every vehicle should be allowed in. Some might carry dangerous cargo, while others are simply lost. Web Application Firewalls (WAFs) work the same way. They stand guard at the entrance of your web application, deciding who gets in and who stays out.

But just like traffic rules, WAFs can be tricky. They’re powerful, but they need the right configuration to do their job effectively.

Why WAFs Became a Necessity

Once upon a time, cybersecurity was simpler. Then came the PCI-DSS (Payment Card Industry Data Security Standard) in 2005. It mandated that organizations handling credit card information had to have a web application firewall. But here’s the twist—PCI-DSS never said you had to run it in blocking mode.

Just having a WAF was enough to meet compliance. Whether it actually protected anything was another story.

What Is a Web Application Firewall?

A WAF analyzes incoming HTTP traffic. It checks for patterns that look suspicious. When it detects a potential attack, it either blocks the request or lets it pass, depending on how it’s set up. Think of it like a border guard, scanning every vehicle and deciding which ones are safe to enter.

But here’s the catch—there’s no industry standard that defines what a WAF should be. Over the years, this led to the emergence of hundreds of WAF products, each with its own flavor.

A Crowded Market with No Common Ground

The WAF market exploded after PCI-DSS came into play. Vendors rushed to offer their version of a web application firewall. Some took existing security tools, added a few features, and rebranded them as WAFs.

Today, there are around 100 commercial WAFs on the market, each claiming to be the best. Gartner tracks a handful of the top ones in their periodic reports, but below that line, 50 to 80 more WAFs fight for a place in the spotlight. And guess what? The market is still fragmented, with no sign of consolidation.

ModSecurity: The Open-Source Champion

In this crowded market, ModSecurity stands out. It’s an open-source WAF running under an Apache license. It’s free, flexible, and widely adopted. Many commercial WAFs actually use ModSecurity under the hood, wrapping it with a polished interface and selling it as a premium product.

About half of the commercial WAFs on the market are built on ModSecurity. Some vendors are transparent about this, while others quietly package it as their own. But the core functionality often remains the same.

How WAFs Work: Traffic Inspection at Its Best

Picture a web application firewall as a security checkpoint at an airport. Passengers (requests) line up, and security checks them against a list of known threats. If a request matches a suspicious pattern, it gets flagged.

Here’s the typical process:

• Inspect Traffic: WAFs analyze HTTP requests as they enter.
  
  
• Apply Patterns: They compare traffic against known attack patterns.
  
  
• Decision Time: Based on the match, they either block or allow the request.
  
  

The result? Only clean traffic gets through. But the complexity of web standards means this process isn’t always foolproof.

Why WAFs Are So Complicated

A network firewall operates on TCP/IP traffic—a relatively simple, structured protocol. But a WAF deals with web traffic, which is anything but simple. Think HTML, CSS, JavaScript, file uploads, API calls, and more.

A network firewall makes binary decisions—allow or deny—based on IP addresses and ports. But a WAF analyzes the content, looking for signs of malicious intent. It’s a whole different ball game.

The Complexity of Web Traffic

The web is messy. Requests can come in all shapes and sizes:

• Static Content: Images, CSS, JavaScript files.
  
  
• Dynamic Requests: APIs, AJAX calls.
  
  
• File Uploads: PDFs, reports, and multimedia.
  
  

A WAF tries to make sense of all this noise and distinguish between good and bad traffic. It’s no wonder that configuring a WAF is a daunting task.

Positive Security vs. Negative Security Models

WAFs operate in two modes:

• Positive Security (Whitelist): Only allow predefined safe requests.
  
  
• Negative Security (Blacklist): Block known bad patterns.
  
  

Most organizations prefer the negative security model because it’s easier to manage. Blocking known threats is simpler than creating a detailed list of what’s safe.

But there’s a downside. False positives—legitimate requests blocked as threats—can frustrate users and lead to operational headaches.

The False Alarm Dilemma

Imagine a car alarm that goes off every time a leaf falls on the windshield. That’s what happens when a WAF generates too many false positives. Security teams drown in noise, making it hard to identify real threats.

To fix this, organizations:

• Run in Audit Mode First: Monitor traffic without blocking.
  
  
• Fine-Tune Rules: Adjust patterns to reduce false positives.
  
  
• Gradually Switch to Blocking Mode: Only after the system is stable.
  
  

Why WAF Management Is Hard

WAFs don’t run themselves. They need constant care and attention. Many organizations buy a WAF, plug it in, and expect magic. But without a dedicated team to manage it, WAFs often become silent spectators.

Logs pile up, alerts go unnoticed, and before long, the WAF is either ignored or disabled. To avoid this fate, organizations need:

• Dedicated Staff: Someone who knows how to fine-tune the WAF.
  
  
• Regular Audits: To identify and reduce false positives.
  
  
• Continuous Learning: Keeping up with evolving threats.
  
  

Why Blocking Mode Matters

A WAF sitting in monitoring mode is like a security camera without a guard. It records everything but does nothing to stop the bad guys. Only when a WAF operates in blocking mode does it become an effective line of defense.

Sure, it takes time and effort to fine-tune a WAF. But once it’s properly configured, it can block real threats while minimizing false positives.

Training and Expertise: The Key to Success

WAFs aren’t plug-and-play. They require expertise. Security teams need to invest in:

• Training: Learning how to configure and manage WAFs.
  
  
• Documentation: Understanding vendor-specific nuances.
  
  
• Ongoing Practice: Staying updated with emerging threats.
  
  

Without this, organizations risk having a WAF that’s either too aggressive (blocking legitimate traffic) or too lenient (letting threats slip through).

Conclusion: Guard Your Web Application the Right Way

A web application firewall is like a security checkpoint for your web app. It’s not perfect, but when configured correctly, it can stop many threats before they reach your servers. ModSecurity continues to dominate the open-source space, while commercial WAFs provide polished, enterprise-ready options.

But here’s the secret—no matter which WAF you choose, its effectiveness depends on how well it’s managed. Don’t let your WAF become another forgotten tool. Dedicate the time and resources needed to make it your most reliable ally in the fight against cyber threats.

Join CISO Platform — the CyberSecurity Community
Gain exclusive insights from top security professionals and access cutting-edge research.
Join Now

By: Christian Folini (Teacher and Security Engineer, Partner, Netnea.com)

When you get into a car, the seatbelt is your first line of defense. It's automatic—click it, and you’re safer. But it doesn’t mean you stop watching the road or ignore traffic rules. A seatbelt reduces the impact, but it’s not a magic shield. The same goes for ModSecurity and the OWASP Core Rule Set (CRS) in web security. They’re the seatbelt for your web applications—basic protection that’s easy to set up and gives a great return on investment.

Why Basic Security Matters

Think about driving. Even with airbags, anti-lock brakes, and lane assist, the seatbelt is your baseline safety. Similarly, a Web Application Firewall (WAF) acts as a seatbelt for your web application. It's not a one-size-fits-all solution, but it significantly reduces the damage from a potential attack.

When configured correctly, ModSecurity and the OWASP CRS block standard, well-known web threats. Attackers need to work much harder to develop exploits that bypass these defenses. And even if they do, there’s a good chance they won’t get the response they need to succeed.

Introducing ModSecurity: The Engine Behind Your Protection

ModSecurity, often called "ModSec," is an open-source web application firewall (WAF). It monitors incoming HTTP traffic and filters out malicious requests. But here’s the catch—ModSecurity itself doesn’t do much without rules.

Imagine a car engine. Without fuel and a properly tuned system, it’s just a block of metal. ModSecurity works the same way. It’s the engine, but the real power lies in the rules that guide it.

The Role of OWASP Core Rule Set (CRS)

Enter the OWASP Core Rule Set (CRS)—the fuel that powers ModSecurity. CRS is a set of carefully curated rules designed to identify and block common web application attacks. From SQL injection to cross-site scripting (XSS), CRS is the intelligence that makes ModSecurity effective.

ModSecurity alone can’t protect you. But when paired with CRS, it becomes a formidable line of defense against malicious traffic. It's like giving your car the best fuel and fine-tuning the engine for maximum performance.

What’s Under the Hood: How ModSecurity and CRS Work Together

Picture a highway. Cars are zipping by, and you need to identify which ones are safe and which ones might be dangerous. ModSecurity sits at the entrance, analyzing every car (HTTP request) that passes through. CRS is the guidebook, telling ModSecurity what to look for and what to block.

Here’s how it plays out:

• ModSecurity intercepts incoming requests.
  
  
• CRS evaluates the requests using predefined rules.
  
  
• If the request matches a known attack pattern, it’s blocked.
  
  
• Legitimate requests continue to their destination, ensuring business as usual.

Why It’s Not a Silver Bullet

Much like a seatbelt, ModSecurity and CRS are not perfect. They’re a solid starting point, but they won’t stop everything. False positives—when legitimate traffic gets flagged as malicious—can spoil the experience. However, with fine-tuning and ongoing maintenance, false positives become manageable.

Christian Folini, a co-lead of the OWASP CRS Project, explains it best: "A web application firewall, when done properly, is a good return on investment... but it's no silver bullet."

Security teams need to stay vigilant, just like drivers still need to stay alert even with seatbelts and airbags.

Handling False Positives: Fine-Tuning for Accuracy

False positives can make managing a WAF frustrating. Imagine your seatbelt tightening unnecessarily every few minutes while driving—annoying, right? ModSecurity and CRS can trigger similar "false alarms," blocking harmless traffic.

To address this:

• Audit Mode: Start with audit mode to identify false positives without blocking traffic.
  
  
• Custom Rules: Adjust CRS rules to better fit your application.
  
  
• Exception Handling: Allow safe traffic while maintaining high security.
  
  

Why ModSecurity and CRS Are a Worthy Investment

Security is about layers. A WAF isn’t the only layer, but it’s an essential one. ModSecurity and CRS give you:

• Baseline Protection: Immediate defense against common attacks.
  
  
• Time to Respond: Slows down attackers, giving you more time to detect and mitigate threats.
  
  
• Better ROI: Low-cost, high-impact protection for web applications.
  
  

Getting Started: Setup and Configuration

Ready to install ModSecurity and CRS? Here’s a simple guide:

1. Install ModSecurity: Available as a module for Apache, Nginx, and IIS.
   
   
2. Download and Integrate CRS: Fetch the latest version of the OWASP CRS.
   
   
3. Test in Audit Mode: Identify potential false positives.
   
   
4. Switch to Blocking Mode: Once configured, enable full protection.
   
   

What Happens If You Ignore It?

Driving without a seatbelt is risky. Similarly, running a web application without a WAF is asking for trouble. You leave the door open for:

• SQL Injections: Attackers manipulate your database.
  
  
• XSS Attacks: Injecting malicious scripts into your site.
  
  
• Brute Force Attacks: Repeated login attempts to gain unauthorized access.

Without ModSecurity and CRS, these threats could slip through unnoticed.

Christian Folini: The Man Behind the Protection

Christian Folini, a security engineer, speaker, and co-lead of the OWASP CRS Project, is a driving force behind improving ModSecurity’s capabilities. As the author of the ModSecurity Handbook (2nd edition), he’s dedicated to helping security professionals get the most out of their WAF setups.

Folini’s contributions to the community ensure that security teams have free access to top-tier protection. His passion for cybersecurity has led to a wealth of free resources, online classes, and in-depth training sessions.

Demo and Hands-On Insights: Putting Theory into Practice

Folini doesn’t just talk about ModSecurity—he demonstrates it. His extensive demos walk users through installation, configuration, and managing false positives. In his sessions, he uses security scanners to show real-world scenarios where ModSecurity and CRS make a tangible difference.

Conclusion: Seatbelt on, Safety Up!

Just like a seatbelt is a must-have for every car ride, ModSecurity and the OWASP Core Rule Set are non-negotiables for web applications. They’re your first line of defense, giving you a strong start while you layer on other security measures.

Don’t leave your web application unprotected. Buckle up with ModSecurity and CRS, and stay safe on the digital highway.

Join CISO Platform — the CyberSecurity Community
Gain exclusive insights from top security professionals and access cutting-edge research.
Join Now

By: Christian Folini (Teacher and Security Engineer, Partner, Netnea.com)

Introduction

Imagine your home guarded by a loyal family dog. It’s friendly, greets your guests, and barks only when a real threat emerges. But what happens when that same dog is suddenly tasked with guarding a high-security vault? It transforms into a fierce guard dog, ready to pounce at the slightest sign of intrusion. This is exactly how OWASP ModSecurity Core Rule Set (CRS) behaves—switching between a family-friendly pet and an untamed protector depending on its Paranoia Level (PL).

As cyber threats become more sophisticated, security professionals need a fine balance between protection and flexibility. CRS achieves that balance by allowing organizations to set different Paranoia Levels to detect and prevent web-based attacks. The deeper we dive into these levels, the more aggressive and precise the rules become.

Understanding Paranoia Levels: Dog Metaphor Edition 

Let’s break down Paranoia Levels with a fun analogy. Picture a dog that adjusts its behavior based on its environment:

• Paranoia Level 1: The family dog. Friendly, welcoming, and reacts only to obvious intruders. This level minimizes false positives and is suitable for most internet-facing applications. Basic protection with minimal fuss.
  
  
• Paranoia Level 2: A suspicious watchdog. It sniffs out trouble more often, but occasionally mistakes a friendly neighbor for an intruder. It’s perfect for online shops or applications dealing with real user data.
  
  
• Paranoia Level 3: The guard dog. Barking at every knock on the door. It monitors closely and is ideal for high-stakes environments like online banking, where every transaction is under the microscope.
  
  
• Paranoia Level 4: The mad dog. Ready to pounce at the slightest provocation. It's hyper-vigilant but needs constant training to distinguish between threats and friendly visitors. Reserved for applications where nothing less than nuclear-grade security will do—think military institutions or nuclear plants.
  
  

Why Paranoia Levels Matter

Security is never one-size-fits-all. An online shopping portal doesn’t need the same level of security as a classified government database. CRS allows you to adjust the rules depending on your application’s sensitivity.

Here’s the breakdown:

• PL 1: Baseline security for any internet-facing service. Minimal false positives. Ideal for public websites.
  
  
• PL 2: Enhanced security for services handling sensitive data. A few false positives are expected. E-commerce platforms fit this bill.
  
  
• PL 3: Stringent security with specialized rules. Requires experienced handlers to manage false positives. Online banking services or financial institutions fall here.
  
  
• PL 4: Maximum security for mission-critical applications. High false positives, but top-notch protection. Perfect for high-stakes infrastructures.
  
  

Training the Mad Dog: False Positives and Rule Tuning

Running Paranoia Level 4 without training is like leaving a guard dog untrained—it bites everyone, even the mailman. False positives are the bane of high paranoia levels. When the rules get stricter, they sometimes mistake legitimate requests for malicious activity.

False Positives Explained:

• A friendly guest mistaken for an intruder? False positive.
  
  
• An actual attacker identified as a threat? Success.
  
  

To prevent unnecessary “bites,” security teams invest time training CRS, writing rule exclusions, and continuously testing. This ongoing effort is crucial for environments operating at PL 3 or PL 4.

Why Training Matters:

• New software releases introduce new traffic patterns—just like a new mailman visiting the house.
  
  
• False positives lead to unnecessary blocking of legitimate traffic, affecting user experience.
  
  
• Writing exclusions and tuning rules smooths the guard dog’s responses, ensuring a balance between security and user access.
  
  

Diving Deeper: Rule Groups and Their Importance

CRS rules are grouped by topic and assigned unique IDs. Think of these as commands given to the guard dog to recognize various threats. These rule groups cover a wide range of attack vectors, from protocol enforcement to SQL injection prevention.

Key Rule Groups:

• 920 Protocol Enforcement: Ensures HTTP protocol compliance.
  
  
• 930 Local File Inclusion Protection: Prevents unauthorized file access.
  
  
• 932 Remote Command Execution Detection: Blocks shell command injections.
  
  
• 941 SQL Injection Detection: Protects against SQL-based attacks.
  
  
• 942 Cross-Site Scripting (XSS) Prevention: Identifies and stops malicious scripts.
  
  
• 949 Blocking Evaluation: Determines whether to block or allow the request.
  
  

The Art of Stricter Siblings: Evolving Paranoia with Rule Layers

CRS introduces a clever concept—stricter siblings. Each base rule has stricter versions at higher Paranoia Levels. Think of it as a family of rules where each sibling is more disciplined and less forgiving.

Example: Byte Range Enforcement

• PL 1 (Base Rule): Allows the full ASCII range except null characters.
  
  
• PL 2 (Stricter Sibling): Accepts only visible ASCII characters, plus tab and newline.
  
  
• PL 3: Narrows the range further by excluding special characters like the percent sign.
  
  
• PL 4: Allows only a minimal set of characters, treating everything else as suspicious.
  
  

This layered approach ensures that as the paranoia level increases, the rules become more rigorous—like a family dog transforming into a SWAT-trained protector.

Paranoia in Action: Making a Reasonable Decision

When deploying CRS, security teams need to assess the value of the data being protected. A business hosting sensitive customer data should aim for Paranoia Level 2 or 3. However, a financial institution processing millions of transactions may consider Paranoia Level 4 worth the investment—despite the effort required to tame the false positives.

Decision-Making in Action:

1. Evaluate the Application: How valuable is the data? What are the potential risks?
   
   
2. Discuss with Stakeholders: Involve developers, security teams, and business units.
   
   
3. Set the Right Level: Balance security with operational efficiency.
   
   
4. Allocate Time for Rule Tuning: Be ready to invest 4-6 days for false positive management.
   
   

Conclusion: Strike the Right Balance

OWASP ModSecurity Core Rule Set empowers organizations to choose their security posture wisely. Whether it’s a family dog watching the front yard or a military-trained guard dog protecting the crown jewels, CRS adapts to the situation. Paranoia Levels give security professionals the power to fine-tune protection without compromising performance.

For Chief Information Security Officers (CISOs) and cybersecurity teams, finding the right level is like striking a balance between vigilance and trust. With the right Paranoia Level and some dedicated training, CRS can be the perfect guard dog—friendly when needed, ferocious when required.

Join CISO Platform — the CyberSecurity Community
Gain exclusive insights from top security professionals and access cutting-edge research.
Join Now

By: Christian Folini (Teacher and Security Engineer, Partner, Netnea.com)

Unmasking Threats with Rule Validation and Scoring

Think about securing your home. You’ve installed surveillance cameras, sensors, and even a guard dog. But what happens when someone manages to sneak in? Wouldn’t it be great to have a system that not only detects the intruder but also evaluates the level of threat?

That’s where OWASP ModSecurity Core Rule Set (CRS) Part 6 steps in. It digs into the error logs, interprets patterns, and scores threats to decide whether to block or allow requests.

Error Logs: The Hidden Story

The real action happens behind the scenes—in the error log. Every suspicious request triggers a rule, and these rules write details to the error log. But reading through raw logs is like looking for a needle in a haystack.

Here’s where unique request IDs come into play:

• Unique Identifiers: Every request is assigned a unique ID that ties the access log and the error log together.
  
  
• Pattern Matching: Alerts appear in the error log, giving insights into what triggered the rule.
  
  
• Deep Analysis: You can search for this unique ID in the error log to uncover what ModSecurity flagged and why.
  
  

Think of the error log as a detective’s notebook. Every clue points to something bigger.

Rule Matching and Scoring

In this part of the CRS journey, we encounter the concept of scoring and rule matching. Imagine a system where each suspicious activity adds points to an overall score. When the score exceeds a defined threshold, action is taken.

1. Paranoia Levels and Strictness

CRS operates at different paranoia levels. The higher the level, the stricter the rule enforcement.

• Paranoia Level 1: Basic protection, fewer false positives.
  
  
• Paranoia Level 4: Ultra-strict, catching everything but often leading to higher false positives.
  
  

In this scenario, a request triggered rules at Paranoia Level 4, where strict character sets are enforced. Even a single invalid byte can trigger an alert.

Rule IDs and Their Messages

Each alert comes with a rule ID that points to the exact rule that was triggered. Here’s a quick breakdown:

• Rule 920273: Invalid characters in the request. This rule enforces strict ASCII character checks, flagging any deviation.
  
  
• OS File Access Attempt: CRS knows when a sensitive file path is requested (like /etc/passwd). This triggers a critical alert.
  
  
• Remote Command Execution (RCE): Certain patterns hint at potential RCE attempts, adding more points to the score.
  
  

These rules not only alert you but also score the request. A higher score increases the likelihood that the request is malicious.

The Scoring Game: Block or Pass?

ModSecurity works like a scoring system in a video game. Each violation adds points. If the score crosses a certain threshold, the request is blocked.

• Threshold Set to 5: Initially, the threshold was relaxed, allowing most requests to pass.
  
  
• Threshold Lowered Back to 5: After analysis, the threshold was returned to its original value. The system started blocking suspicious requests again.
  
  

When the threshold is low, even minor violations get blocked. But if the threshold is high, only severe attacks trigger a block.

Validating Rules in Action

Here’s where things get interesting. After detecting a suspicious request, the analyst dives into the error log.

• Error Log Analysis: Searching for the unique request ID reveals a list of triggered rules.
  
  
• Rule Patterns Identified: Complex patterns and parameter matches expose the potential attack.
  
  
• Scoring Validation: Each rule adds to the overall score, ultimately deciding whether to allow or block the request.
  
  

In one instance, a search query included a suspicious string:

bash

CopyEdit

cat /etc/passwd

This immediately triggered an OS File Access Attempt rule. But the magic happens when multiple rules combine and push the score past the threshold.

Real-World Threat Validation

Security teams often run security scanners like Burp Suite or Nikto to validate CRS configurations.

1. Nikto – The Fast but Weak Scanner

Nikto is fast, but not the smartest scanner. It runs through 3,296 requests in seconds, generating alerts for 7 rules per request.

• 41,000 Entries in the Log: Almost all requests triggered ModSecurity rules.
  
  
• Blocked with Access Denied (403): CRS aggressively blocked Nikto’s requests, marking them as suspicious.
  
  

2. ModSecurity Alias for Easier Analysis

To make log analysis easier, security experts often create shell aliases that group and format error logs. This allows them to:

 Quickly search and grep for relevant request IDs.
Extract and categorize rule messages.
  Count alerts and analyze blocking behavior.

Access Denied: The Final Block

When a request crosses the score threshold, Rule 949110 steps in.

• Access Denied with Code 403: This rule blocks the request, marking it as malicious.
  
  
• No More Warnings: Unlike previous warnings, this rule ensures that suspicious traffic is denied access.
  
  

Without this block, an attacker could bypass security controls and access sensitive data.

Lessons for Cybersecurity Leaders

For CISOs, CIOs, and Security Managers, understanding CRS Part 6 is essential for fine-tuning security rules.

• Log Analysis is Key: Reviewing error logs helps uncover rule patterns and improve configurations.
  
  
• Adjusting Paranoia Levels: Tuning paranoia levels can balance security and usability.
  
  
• Threshold Management: Setting the right threshold ensures that false positives don’t disrupt operations.
  
  

Testing and Fine-Tuning CRS

Testing CRS is not a one-time effort. Security teams should:

Regularly Run Security Scans: Use scanners like Nikto and Burp Suite to evaluate CRS effectiveness.
Analyze Logs for Insights: Search for unique IDs to correlate request logs and error logs.
Optimize Rule Sets: Adjust thresholds and fine-tune rules based on real-world traffic.

Final Thoughts

Mastering the OWASP ModSecurity Core Rule Set isn’t just about setting it up and forgetting it. It’s about constantly validating, adjusting, and fine-tuning the system.

CRS Part 6 empowers security teams to:

 Analyze error logs for patterns.
  Identify suspicious requests through scoring.
  Block malicious traffic before it causes damage.

Stay vigilant. Fine-tune your CRS. Block the threats before they breach your digital walls.

Join CISO Platform — the CyberSecurity Community
Gain exclusive insights from top security professionals and access cutting-edge research.
Join Now

By: Christian Folini (Teacher and Security Engineer, Partner, Netnea.com)