Risk or Threat Oriented Security: Which Path Should We Choose?

Lately, I've been engaged in various discussions about what should drive our security efforts: risk or threats. It's an interesting debate, and today I want to explore it with you in a more engaging and enjoyable way.

Let's start with the risk-based approach. Ideally, this is the way to go. It involves identifying the key assets and evaluating the likelihood and potential impact of negative events to them. We often refer to these key assets as the "Crown Jewels." By understanding the likelihood and impact of those bad events, we can allocate appropriate resources to protect them effectively.

On the other hand, there's the threat-oriented perspective. Here, the focus is less on identifying the potential impact and likelihood of events and more on pinpointing threat activity that is likely to target our organization. For instance, organizations adopting a threat-oriented view would identify the most common malware families affecting similar organizations and implement controls to prevent, detect, and respond to them.

Big parenthesis here; talking about threat vs risk doesn’t make much sense from a purist point of view, as threat is part of risk. But for simplification purposes, I’d say that the “risk oriented” view is focused on key assets, while “threat oriented” is focused on threats.

So, while risk-based efforts revolve around safeguarding high-impact assets, threat-based efforts emphasize countering prevalent threats. The typical security operations professionals tend to prefer the threat-based approach. They observe a direct correlation between the perceived threats and incidents, leading them to concentrate on malware prevention, threat intelligence acquisition, and detection techniques.

Conversely, data security professionals, security architects, and risk managers are usually more inclined toward the risk-based approach. They want to first identify what truly matters and needs protection and then design controls around those assets. This approach helps optimize efforts by focusing resources on mitigating risks instead of wasting them on prevalent but relatively harmless threats.

The "threat team" argues that it makes sense to protect against the activity they observe, regardless of the nature and location of the key assets. For them, the effort of identifying key assets takes too long and is never accurate enough to be useful.

Both teams aim to optimize efforts, but they take different approaches. So, why the disparity?

The choice between risk and threat orientation depends on several variables, such as the type and size of the business, the potential classes of impact, and even the profile of the security team. Asking a team with a background in security operations to work in a risk-based manner might not yield the best results, just as asking data security or risk managers to operate in a threat-oriented fashion might not be as effective.

Adopting a risk-based mindset helps us avoid the trap of pursuing absolute security or overspending on protection. On the other hand, threat orientation ensures that our security measures align with real-world threat activity observed in other organizations.

Striking a balance is crucial. This debate can only yield a wrong answer when it tries to find a definitive, one-sided solution.

From my personal perspective, the threat-based approach has always appeared more pragmatic. However, there are many edge cases where it may result in unnecessary efforts or misguided focus. If I had to provide a single answer, I would suggest:

"Do it in a threat-based manner, but always conduct a sanity check considering your key processes and assets."

Now, I'd love to hear your thoughts. How would you approach this challenge?

Log4J everywhere

 

Cybersecurity Is Not A Pair Of Sneakers

"Just do it" does not work for cybersecurity.

 

I've seen many comparisons with very complex things we've managed to accomplish. Man on the Moon, robots on Mars, etc. "We've manged to do all those things, how come there are still breaches happening?". Why can't we take a "just do it" approach for cybersecurity?

 

Well, for many reasons. 

 

First, resources available. The cost of the Apollo program was around $257 BILLION (inflation adjusted). That was all spent on a very specific, point in time objective, to put a man on the Moon. Some might say we've been spending close to that every year on security, but that's for the entire global cybersecurity market. Project Apollo built only 15 flight-capable Saturn V rockers.  

The Saturn V Rocket

 

The world spends hundreds of billions in cybersecurity every year, but that money is to cover all organizations out there. There's an estimate of 300 million business worldwide. Of course, the majority are SMB, but that means the annual average expense in cybersecurity is less than a thousand dollars. There is a lot of money on this business, but it is spread thin and unevenly.

 

Second, it is a moving target. All the technology and ingenuity embarked on the Curiosity rover is impressive, a feat of engineering. It came with a $2.5B price tag, and it has been performing remarkably well. But how successful would Curiosity be if we just decided to drop it in Venus? Or Jupiter?

 

The Curiosity Mars Rover

Venus atmosphere is extremely hot and dense. The surface level pressure is almost a hundred times Earth's atmosphere or almost 20.000 times Mars atmosphere. To make things worse, there are cloud of highly corrosive sulfuric acid. As advanced as the Mars rover is, it wouldn't survive in Venus.

 

In cybersecurity we are often judged by how well our Mars rovers perform in Venus like environments. The conditions where the technology operates change dramatically. Look at all the technology changes we've been experiencing in the last 20 years. We are talking about a period when Amazon, Google and Facebook surged from startups to corporate behemoths, smartphones and tablets became ubiquitous and the web moved from 1 to 2.0 and then to the cloud. The field where cybersecurity plays now is different than what it was in 2015, 2010 or 2001. Have we managed to "solve the security problem"? We would do extremely well playing in that 2001, maybe even the 2010 scenario but the goalposts have moved from there and are still moving ahead.

 

And last, the major issue we face, the "sentient adversary". What does that mean? It means we are not solving a fixed problem. From a problem domain perspective, we are not dealing with engineering, it is game theory. We have a non-zero-sum game to deal with. Our "problem" has smart people on the other side, with motivations and constantly developing new strategies to win. Together with the changing playing field from point #2, it makes a considerable challenge. The problem today is not the same as yesterday, and it will be different tomorrow as well. The adversaries think "outside the box", putting cybersecurity in a domain where it can't be solved even by existing AI bleeding-edge technology. The adversary puts cybersecurity in the same realm as crime and terrorism. We can't just "solve it".

 

"Just Do It" may work as a sneakers slogan, but for cybersecurity, the approach must be different.  In this space what we need is the OODA loop: Observe, Orient, Decide, Act*. Not as catchy, but it gives a chance to survive to fight another day.

 

 

* For cybersecurity I like to use "Adapt" instead of "Act", but the spirit is the same.

Do Not Look For A Root Cause

Reading about root cause analysis (RCA) for security breaches really freaks me out.

Root causes are behind accidents and other unintentional events. Not breaches.

Do you want to know the root cause of a breach? No, it is not a vulnerability that was left unpatched. If you follow the chain of events, someone decided to look for it, assembled a plan of attack, was driven by a motivation...all that at the attacker side.

Defence should look at breaches from a multi-factor point of view. Many things have to go wrong for an attack to be successful and cause harm. You may have a vulnerability providing initial access, but what about allowing privileged access? Lateral movement? Exfiltration, or mass encryption for impact? And why weren't you able to detect and respond to each one of those steps?

Post-mortem analysis usually take the approach of looking at multiple points and is better suited for security incidents. I usually do not like to use project management techniques for security needs, but on this case, I believe it makes sense.

In short, no RCA for your breaches. Take a broader approach and perform a post-mortem analysis.

Professional Certifications, Reboot!

 

After two months and a few hundred dollars later, my most recent personal project is completed. 10 years after my TOGAF9 certification, I decided to play the test taker again and obtain a new batch of professional certifications: AWS Certified Cloud Practitioner, AWS Certified Security Specialty and Microsoft Certified: Azure Fundamentals.

 

I didn't need these certifications for my current job, and I'm not looking for a new one either, so this is not about job requirements or job hunting. So why did I do it?

 

I did it because I could do it :-) Well, ok, let me elaborate a bit. My career has been slowly moving away from more technical roles, and that's reducing my direct, hands on contact with technology. I don't think this is a bad thing, but as someone with the technical background, I miss that deeper understanding of the things I need to talk and write about.

 

At the same time, I do not have the same drive to learn things that I do not have an immediate need for, learning just for the sake of learning. I still love learning new things, but that youth drive of building labs and labs for learning things we may never touch as part of our job is just not there anymore. Putting a target like a certification in front of me (and paying for it) seems to be an effective way to trigger my brain into "I need to learn this" mode. I learned many things in the past while preparing for getting certs, so I thought I could use the same method again. It was nice, it worked well for this intent.

 

Cloud adoption keeps growing and cloud is directly affecting the work of anyone in security these days. It's not different for me: I work for a Cloud SIEM vendor, and we are bringing many innovations to the SIEM space that are directly related to cloud. Securonix recently announced "Bring Your Own Cloud", for example, and it is deeply rooted in AWS offerings, so it seemed natural to me that I should put a couple of AWS certs in my project. AWS Cloud Practitioner helped me learn more about the very broad range of offerings from AWS, and the security specialty was useful to provide more depth to my understanding of cloud threats and cloud security controls.

 

In addition to the AWS certs, I wanted to add the (ISC)2 CCSP to the mix as well. I checked the domain of knowledge of the cert, ran through a few practice exams and noticed I already had most of the skills and knowledge required to pass it. So why didn't I do it? Because it's freaking expensive! USD600 is beyond any reasonable justification for a simple multiple-choice exam. Maybe I would take it if I was looking for a job like cloud security architect, or even as a CISO for a company with a strong cloud presence, but just for the fun of doing it? No, I'm sorry, it doesn't make any sense. 

 

An Azure cert was a natural choice to complete my project. AWS and Azure are by far the most visible cloud providers (sorry Google!), so going through the process for both looked like the best choice.

 

There are a few things I noticed during this exercise that I think it's worth sharing. First, it confirmed to me that test taking talent is really a thing. I'm a helluva test taker. I'm not bragging; apart from helping me pass tests and exams easily, it doesn't provide me with any real competitive advantage "on the job". I've always been like that and was happy to see I haven't lost it after so many years without sitting for a test. I didn’t spend more than a handful of hours reading for the full project. I don’t feel nervous and even have fun while taking the tests, so everything was a fun experience.

 

But when you are a hiring manager and you see those certs in a resume, it's always important to find out if those certs came from real experience or just from good test taking skills (or worse, memorizing those awful brain dumps).

 

Don't get me wrong, it doesn't mean that certs on a resume means nothing. Remember, the main reason for me to do it was to force me into learning something about those technologies. Even if I don't have the hands-on experience the test developers were trying to verify with these exams, I still had to at least read a bit and get solid understanding of the basic concepts. 

 

Talking about basic concepts...if you want to get certs, LEARN THE F* BASICS! You can't believe the number of questions I was able to answer because of basic stuff, not necessarily tied to those specific cloud providers. If you know how crypto works, for example, a lot of the AWS security specialty questions will be very easy to answer. Same thing for networking and network security. AWS security groups, network ACLs, Azure network security groups...those are straightforward to learn when you know those things well. I didn't take the real CCSP, but the practice questions I've done indicate that CISSP level concepts would put more than half of way behind you on that one.

 

Finally, some interesting bits about AWS and Azure I was able to notice:

 

·      Knowing the basics of one of those means you have almost all the basics of the other. Key concepts are virtually identical. 

·      The naming convention of Azure is AWESOME. It's very easy to know what products and services do just from their names. They may not sound as sexy as "Athena", "Glacier", or high tech as “S3”, “EC2”, but they tell you in a very simple manner what they are about.

·      Both services are evolving so fast it's hard to keep study material, documentation and questions aligned and up to date on the latest offerings. Don't be surprised to see questions about things you didn't see in your study material. Check some of the announcements and blog posts from the past year as part of your study work.

·      AWS Security Specialty is the one I see closest to being "hard". There's really a lot of stuff to cover, in a relatively deep level of detail: Networking, Crypto, IAM, logging, policies syntax and small idiosyncrasies. I can see how it really tries to assess real experience on AWS security.

 

 

Am I done with the certs now? Maybe, not sure. It may become an expensive hobby :-). Well...those Azure security certs do not look that hard, I still have that 50% off voucher for AWS exams and I really need to spend some time learning about Google cloud ;-)

 

P.S. As I’m doing this during the COVID-19 pandemic, I took these tests in the “online proctored” mode. THEY SUCK! I was expecting those VUE, PSI guys would have learned by now how to do it right. No, they tech and processes are horrible. I had problems during the 3 exams, one with PSI (AWS Practitioner), the worst one, and two with VUE. If you are a person that gets anxious or nervous during the exam, this is definitely not for you. Some of the issues I had to go through would take many candidates out of their minds and strongly impair their ability to answer the questions.

The Bright Future of Cloud SIEM

TL;DR: People keep questioning SIEM value, but cloud SIEM makes SIEM so much better. SIEM is now capable of delivering a lot of security value with far less effort from security teams.


The SIEM market is a US$5B market with a two-digit annual growth rate. Still, we keep seeing multiple questions and discussions around SIEM’s role, future and value. Why?

 

There are many reasons, including:

• The high importance of SIEM’s role for security operations: The SIEM is often the foundation of Security Operation Centers and has a critical role in their work. It is natural to see it being constantly evaluated and discussed as it has a role in almost all SOC processes.
• Cost and budget share: SIEM is not cheap. It usually takes a big chunk of the security budget. Organizations will keep trying to reduce it as part of their cost optimization efforts, while vendors of other technologies will keep trying to sell their products as alternatives to tap into existing SIEM budgets.
• Operational effort required: SIEM is definitely not a “set and forget” tool. This is not a deficiency per se, as other technologies, such as EDR, also require people to deliver value. But the concerns about how much effort must be put into SIEM operations is a constant driver of discussions about improvements or even replacements of this technology.
• Multitude of experiences: SIEM has been around for more than 20 years. Many professionals have gone through multiple implementations, sometimes with good experiences, sometimes not so much. I’ve seen many people with very strong opinions on SIEM based on their personal experiences with this type of tool, experiences that many times are not representative of how SIEMs can support security initiatives.
• Evolution of other technologies and of the entire technology landscape: As other technologies evolve, it is inevitable to look at how they impact the role of SIEM. It happened with UEBA, it happened with SOAR, it is happening with XDR. The technology environments where these tools operate are also constantly evolving. Big SAN storage systems came up, virtualization became ubiquitous, big data spread out like wildfire. These changes affect the security tools we use to protect IT environments in multiple ways. Some increased the amount of data to be collected and processed, while others were used to evolve SIEM and make it more scalable and capable.

 

Nothing is more important to those discussions as Cloud SIEM. Not just “hosted” in the cloud, but as a native cloud offering. Why? Because now SIEM vendors can have some control over deployment success. What are you saying, Augusto? Didn’t they have control over the success of their own product before? Yes, that’s true!

As a traditional SIEM vendor, it is very hard for you to ensure the customer will be able to get all the benefits your product can provide. First, they may underestimate the required capacity for their environment. They will end with a sluggish product, overflowing with data, having to deal with adding servers, memory, storage, or even stopping the deployment to rearchitect the whole solution before getting any value from it. I’ve seen countless SIEM deployments dying this way before generating any return of investment.

 

But it doesn’t stop there. They may get the sizing right but underestimate the effort to keep it running. They estimate the number of people to use the SIEM, but they forget that a traditional SIEM requires people to use it but also to keep it running. That means people will spend their time keeping servers running, applying patches (to operating systems, middleware and to the SIEM software too), troubleshooting log collection, ensuring storage doesn’t blow up, and not paying attention to what the SIEM should actually be doing for them. The tool is up and running, but again, not providing any value.

We can see how much the vendor depends on the customer to provide value. And even if the customers do things properly, there are other challenges too. Traditional software allows for high variation of deployments: Customers running on different versions, with different hardware and architecture. How can a vendor distribute SIEM content (parsers, rules, machine learning models, etc) that works in a consistent manner to its customers in this scenario? It just can’t.

Considering these factors, I risk saying that offering a traditional SIEM solution is like the Sisyphus Myth. As much as the vendor tries to deliver value, the solution will eventually fail to achieve the customer objectives. As traditional software, SIEM was really destined to die.

How does the cloud SIEM change this?

First, many challenges on SIEM deployments are related to problems that are completely solved or minimized by the SaaS model. Cloud services are highly scalable and elastic, and SaaS practically eliminates the need to maintain the application and underlying components. Now you have a SIEM that finally scales and does not require an army to keep it running. You can focus on using it appropriately.

Second, a SaaS SIEM puts customers on highly standardized deployments. With most customers running on the same version, without capacity challenges, it’s far easier to deliver content that works for all of them. That makes a huge difference in perceived value. And it doesn’t stop there. With this scenario it becomes easier to the vendor to finally realize the benefits of the “wisdom of the crowds”. Developing more complex ML models for threat detection, for example, becomes easier and more effective. The vendor now has access to more data to train and tune the models. Even simple IOC match detection content can be quickly developed and delivered to all customers, allowing the SIEM vendor to provide detection of new, in the wild threats.

Finally, delivering any software solution via SaaS gives the developer the opportunity to embrace more agile development practices. Upgrading a traditional SIEM deployment is so complex that vendors would naturally rely on traditional waterfall development practices, generating big releases with long times between them. SaaS SIEM can leverage agile development and CI/CD practices, so new features can be quickly added, and defects quickly fixed.

Cloud SIEM is on its infancy when you consider SIEM is just past its teenage years. But there are so many opportunities to explore with this model that I believe now we can say “Next-Gen SIEM” without feeling silly about it. Be careful with “SIEM is dead” claims. That sounds to me much like "I think there is a world market for maybe five computers", by Thomas Watson in 1943.

Some additional words on those SOC robots

 The topic on SOC automation is really a fun one to think about, and even after putting my thoughts into words with my last post, I've still kept thinking about it. Some additional considerations came to my mind.

The simplistic question of "Will machines replace humans in a SOC" can be clearly answered with a NO, as I explained in my previous post. As the human attackers are required to evolve the attacking robots, blue team people are required to update the automated defenses.

But things change if the question is asked with some additional nuance. If you ask "will defense actions be automated end to end, from detection to response actions?", it becomes a more interesting question to answer.

The scenario of automated threats that Anton described in his post will, IMO, require SOCs to put together some end to end automation. Having a human involved for every response will not scale to face those attacks. Humans will be responsible for creating those playbooks and monitor their performance, but they cannot be involved in their execution. We need SOC automation that allows us to detect, investigate and initiate response without human intervention. This is challenging, but we must get there at some point.

Andre Gironda commented on the LinkedIn post pointing to my blog post that even with the appropriate tools he still can't fully automate simple phishing response. I could say he's probably being too perfectionist or doing something wrong, but I actually believe him. I believe automation can provide value by reducing human effort in the SOC right now, but full automation, even for some specific threats, is still challenging. But we'll have to get there if we want to stand a chance.