Security Balance - Augusto Barros

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

noreply@blogger.com (Unknown) — Tue, 06 Jun 2023 19:29:00 +0000

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

noreply@blogger.com (Unknown) — Tue, 14 Dec 2021 20:46:00 +0000

Cybersecurity Is Not A Pair Of Sneakers

noreply@blogger.com (Unknown) — Thu, 14 Oct 2021 21:34:00 +0000

"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

noreply@blogger.com (Unknown) — Fri, 08 Oct 2021 14:25:00 +0000

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!

noreply@blogger.com (Unknown) — Fri, 07 May 2021 16:39:00 +0000

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

noreply@blogger.com (Unknown) — Fri, 16 Apr 2021 20:49:00 +0000

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

noreply@blogger.com (Unknown) — Fri, 19 Mar 2021 21:07:00 +0000

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.

The Robots Are Coming!

noreply@blogger.com (Unknown) — Tue, 16 Mar 2021 21:42:00 +0000

The debate around SOC automation has been a fun one to follow. Allie Mellen wrote a short but on the spot piece about it, reaffirming what seems to be the commonsense opinion on this topic today: Automation is good, but to augment human capacity, not replace it.

After that Anton brought up a very interesting follow up, confirming that view but also pointing to a scary future scenario, where automation would be adopted so extensively by the attackers that it would force defense to do the same. Does this scenario make sense?

I believe it does, and indeed it forces defense to adopt more automation. But even if Anton says the middle ground position is "cheating", I still think it is the most reasonable one. There will never be (until we reach the Singularity) a fully automated SOC, just as there will never be a fully automated attacker (until...you know). Why? Let's look at the scenario Anton painted for this evolved attacker:

• You face the attacker in possession of a machine that can auto-generate reliable zero day exploits and then use them (an upgraded version of what was the subject of 2016 DARPA Grand Challenge)

• You face the attackers who use worms for everything, and these are not the dumb 2003 worms, but these are coded by the best of the best of the offensive “community”

• Your threat assessment indicates that “your” attackers are adopting automation faster than you are and the delta is increasing (and the speed of increase is growing).

Even if it looks scary, this scenario is still limited in certain points. You may have malware capable of creating exploits by itself, but what will they exploit? What is this exploitation trying to accomplish? There is an abstract level of actions that is defined by the creator of the malware. Using MITRE ATT&CK language, the malware is capable of generating multiple instances of a selection of techniques, but a human must define the tactics and select the techniques to be used. Quoting Rumsfeld, there will be more known unknowns, but the unknown unknown is still the realm of humans.

A few years ago, I had a similar discussion with a vendor claiming that their deep learning-based technology would be able to detect"any malware". This is nonsense. Even the most advanced ML still needs to be pointed to some data to look at. If the signal required to detect something is not in that data, there's no miracle. Let's look at a simple example:

• A super network-based detection technology inspects ALL network traffic and can miraculously identify any attack.

• The attacker is on host A in this network, planning to attack host B, connected to the same network

• The attacker scans for Bluetooth devices from host A, finds host B, exploits host B via a Bluetooth exploit

• The super NDR/NIDS tool sits there patiently waiting to see an attack that never traverses the monitored network!

You may claim this is an edge scenario, but I'm using anexaggerated situation on purpose. There’s still many cases that we can relate to, such as breaches due to the use of shadow IT, cloud resources, etc. What I want to highlight is the type of lateral thinking very often employed by attackers in cybersecurity. And the lateral thinking is still exclusive of humans.

What I'm trying to say is that fully automated threats are scary, buy they lack the main force that makes detecting threats challenging. Defense automation can evolve to match the same level, but both sides will still rely on humans to tip the scale when those machines reach a balance point in capabilities.

What we have today is similar to those battling robots TV shows. Machines operated by humans. If things evolve as Anton suggests we will move to what happens in "robot soccer": human created machines operating autonomously, but within a finite framework of capabilities.

Robot wars vs Robot Soccer

Threats and SOCs will become more automated for sure. As they automate, they become faster, so each side has to increase its own level of automation to keep up. But when automation limits are reached, the humans on the threat side must apply that lateral thinking to find other avenues to exploit. They need to take the Kirk approach to Kobayashi Maru. When this happens, the humans on the defense side become critical. They need to figure out what is happening and create new ways to fight against the new methods.

So, humans will still be necessary on both sides. Of course, the operational involvement will be greatly reduced, again, on both sides. But they will be there, waiting to react against the innovation introduced by their counterparts on the other side.

This may be an anticlimactic conclusion, and it is. But there are some interesting follow up conversations to have. The number of humans required, their skills and how they are engaged will be different. What does it mean for outsourcing? Do end users still need people on their side? If solution providers engage this problem in a smart way, we may be able to remove, or greatly reduce, the need for humans on the end user organization side, for example. The remaining humans would be on the vendor side, adapting the tools to react against the latest attacks. For the end user organization, the result may look very similar to full automation, as they would not need to add their humans to the mix. Will we end up with the mythical "SOC in a box"? Future will tell.

An Analysis of Past Mistakes

noreply@blogger.com (Unknown) — Thu, 04 Mar 2021 17:35:00 +0000

As I was looking for an old email in my archives, I stumbled on discussions about a security incident that happened almost 13 years ago. That was that time when, well, there's no other way of saying it....I was hacked.

The good thing about looking at incidents like that one after a long time is that it helps us understand what really happened and also run a less passionate and unbiased assessment of our own actions. I have to say this case is really enlightening, in many ways. There are good lessons to learn and mistakes to acknowledge from multiple perspectives: Technical, Managerial and even Political.

The year was 2008. I was part of the Board for the Brazil ISSA chapter. We were trying to push for a more inclusive posture of the association, promoting free monthly encounters and other initiatives. Our group took over the board when we felt there were too many security vendors dominating the association, many of them pulling things to where their business would benefit most. A group of friends and acquaintances discussed this and after some deliberation, I was chosen as the head of the ballot. It was an honor for me at that time, as each one in that group was capable of taking the central role. We won the election using our network and a popular email discussion board at that time to spread our word and our plans for the association.

So, back to the "breach". We had set up a portal for the association using an open source CMS, Joomla. Joomla was plagued by vulnerabilities at that time, and someone managed to access the user database and crack the passwords. The password for my test account there...well, I was using it in some other places. It was my old password from before I started working with security. I had replaced it almost everywhere, but it was still used on a few places I had forgot about, like LinkedIn and a hotmail account I used to have so I could use MS Messenger. Well, those, and a couple of other services were quickly found by the attackers, and an embarrassing message with all that was posted in that popular email forum, and other places. In summary, an application breach on a website ran by...security professionals, and some pretty lame secops practices by one those guys exposed.

What have I been able to extract from that incident? A lot. Here it is.

Technical lessons

The easiest to mention. We were using a horrible tool from a security perspective (Joomla). We had been warned by some people, but some of our group believed we could run it securely by not using crappy plugins and keeping it always up to date. But we didn't have a dedicated security operations team to keep watching it. In addition to it, we knew there were technically competent people out there trying to hack us. So, the threat component was high. It was an explosive combination. In short, we should have made choices that would simplify the challenge of keeping the vulnerability profile low, as we didn't have time to protect it like it should be.

Then, there was my own personal mistake, reusing a password. It is certainly something no one, especially a security professional, should do. Of course, I was already aware of that, and I was already using unique, different passwords on almost everything that mattered at that time. But this old password ("trustno1", if you really wanna know!) was something I started using long before getting involved with security. As I became more aware of the risks of password reuse I started changing it everywhere, but there were still a few places I had forgotten to do it. To make things worse, I started using it as my "throwaway" password for testing needs. An account I had for testing on the ISSA chapter website was using that password. Bad secops…bang, they got me.

Management Lessons

This is where I think we can start getting good lessons from the incident. This is about our organizations, the ISSA chapter. How come a security professionals organization be hacked?

We fell for the same mistakes we see in many other organizations. First, the fact that we were all security people caused the "too many cooks in the kitchen" issue. Who was the "CISO" for our organization? That was never defined, so there weren't clear roles and responsibilities defined regarding our own security. I brought the site up and did some of the initial hardening, but at that time I was already moving those responsibilities to other people and completely focused on other issues (I was preparing to move to Canada at that time). People generally know about vulnerability management, but on that case, I believe no one was actually the owner of that process and consciously doing it for us.

Political, social and relationship lessons

Here's another point from where I extract a lot of personal lessons. When we took over the chapter, our group had as one of its objectives to close the gap between the "security professionals" community (the CISSPs :-)), in fact those dealing with risk management, security policies and other less technology oriented topics, and those with the technology background or IT security jobs. That should also include the "hacking" community (or "scene").

That divide between the "management people" and the "technical people" was also related to professionals in different stages in their careers. It was very hard to find technical individual contributors in a highly paid position in Brazil at that time. It wasn't interesting to make them part of ISSA for some of the previous directors because there was low value in junior people as potential customers to their products and services. Trying to be more inclusive of professionals with technical backgrounds was really the attempt to make the association useful for people in the early stages of their careers as well.

But although I have a technical background, I was never close the underground scene in Brazil. I knew people who were, some volunteers helping us during those days were very connected to that community. Still, I've never been a fan of some of the more juvenile aspects of hacking communities. The use of leetspeak, piercings, crazy haircuts...nothing against that, it's just not my thing. This, on top of my effort to make the technical professionals voices heard in the community, made me adopt a gatekeeping position, as in my view they were not being helpful in solving the problem I wanted to solve. In more traditional environments, appearances matter a lot. At that time, it was hard to be taken seriously wearing shorts, a mohawk and writing “3 n0iZ M4n0!!”.

In the end, I believe we didn't do enough to reach out and include them, and they felt excluded. Our posture about a "professional organization", plus a growing number of charlatans in the market put fire in a "take down a whitehat" movement, which I ultimately fell victim of.

I had helped create the animosity against security professionals, then underestimated their abilities and their motivations against me. What a stupid combination, right? Yes, I know. Talk about not having control over the "Threat" component of the risk equation...

In summary, that was my collection of mistakes. Technical blunders, classical management mistakes and a dose of simple immaturity. For those also hurt in the process, I'm sorry. I hope I can keep learning from mistakes like those and make better decisions in the future. This is an extremely important part of working in security, knowing we'll never be able to reach perfection.

Monitoring and Vulnerability Management

noreply@blogger.com (Unknown) — Fri, 09 Oct 2020 15:27:00 +0000

(Cross posted from the Securonix Blog)

Vulnerability management is one of the most basic security hygiene practices organizations must have in place to avoid being hacked. However, even being a primary security control doesn't make it simple to successfully implement. I used to cover VM in my Gartner days, and it was sad to see how many organizations were not doing it properly.

Many security professionals see VM as a boring topic, usually seeing it simply as a "scan and patch" cycle. Although the bulk of a typical VM program may indeed be based on the processes of scanning for vulnerabilities and applying patches, there are many other things that need to be done so it can deliver the expected results.

One of the most important pieces of it is the prioritization of findings. It is clear to most organizations that patching every open vulnerability is just not feasible. If you can't patch everything, what should you patch first? There are many interesting advancements in this area. What used to be based only on the severity of the vulnerabilities (the old CVSS value) is now a more sophisticated process that leverages multiple data points, including threat intelligence. The EPSS research by Kenna Security is a great example of how evolved the practice of prioritizing vulnerabilities is now when compared to the old CVSS times.

But even when you are able to decide what to patch first, there are also cases where the remediation is not simply applying a patch. Some vulnerabilities involve not only a bug, but also other issues such as the existence of legacy software and protocols in the environment. These situations usually require a more complex approach, and that's where an additional component of the VM process, the compensating controls, become important.

Compensating controls are used to address the risk of a vulnerability while the full remediation cannot be applied. Using an IPS, for example, is a typical compensating control. You can use them when you cannot apply the remediation, such as when a patch is not available, or to mitigate the risk until you are comfortable enough (usually after testing is done, during a maintenance window) to apply it. We usually see some security controls that can avoid or reduce the impact of vulnerability exploitation as the ideal candidates for compensating risk, but there is something I always like to bring up during this discussion: Monitoring.

Think about it for a second. You have an open vulnerability that you still cannot patch. The exploit is available, as well as a lot of information about how it is used. Even if you cannot avoid it, you can use all this information to build a security monitoring use case focused on the exploitation of this specific vulnerability. You it is there, and that there is a chance for it being exploited, so why not put something together to look for that exploitation? You can prioritize the alerts generated by this use case, as you know you are currently vulnerable to that type of attack.

A great example of using security monitoring as part of the VM process is what is happening with the new Windows Zerologon EP (ZEP) vulnerability (CVE-2020-1472). The issue is complex and requires more than just applying a patch. Our VP of Threat Research, Oleg Kolesnikov, produced a great write-up about the details and also variants of exploitation and detection. In summary, Microsoft has provided a patch for the immediate problem, but some third-party systems may still use an older, vulnerable version of Netlogon secure channel connections. To avoid breaking functionality of existing systems, Microsoft has introduced new events in their logs to identify the use of these older versions, and signaled they will move to an enforcement mode that will not accept them anymore after February, 2021.

This is where aligning monitoring with the remediation process becomes so important. The new events added by Microsoft can help identify attack attempts and track other vulnerable systems on the network. A pre-established process to coordinate the use of monitoring tools and infrastructure as an additional compensating control for VM can help in situations like this, where the plan to handle a vulnerability also requires monitoring activities.

DDLC - Detection Development Life Cycle

noreply@blogger.com (Unknown) — Mon, 21 Sep 2020 19:55:00 +0000

Dr. Chuvakin has recently delivered another great blog post about "detection as code". I was glad to read it because it was the typical discussion we used have in our brainstorming conversations at Gartner. It had a nice nostalgic feeling :-). But it also reminded me of my favorite paper from those times, "How To Develop and Maintain Security Monitoring Use Cases".

That paper describes a process framework for organizations to identify and develop use cases for security monitoring. It was intentionally designed to be tool neutral, so it could be used to develop SIEM rules, IDS signatures or any other type of content used by security monitoring tools. It was also built to mimic Agile development processes, to avoid the capital mistake of killing the required agility to adapt to threats by too much process. I had fun discussions with great minds like Alex Sieira and Alex Teixeira (what's this with Alexes and security?) when developing some of the ideas for that paper.

Reading the philosophical musings from Anton on "detection as code" (DaaC?), I realized that most of threat detection is code already. All the "content" covered by our process framework is developed and maintained as code, so I believe we are quite close, from a technology perspective, to DaaC. What I think we really need is a DDLC - Detection Development Life Cycle. In retrospect I believe our paper would be more popular if we used that as a catchy title. Here's a free tip for the great analysts responsible for future updates ;-)

Anyway, I believe there are a few things missing to get to real DaaC and DDLC. Among them:

Testing and QA. We suck at effectively testing detection content. Most detection tools have no capabilities to help with it. Meanwhile, the software development world has robust processes and tools to test what is developed. There are, however, some interesting steps in that direction for detection content. BAS tools are becoming more popular and integrated to detection tools, so the development of new content can be connected to testing scenarios performed by those tools. Just like automated test cases for apps, but for detection content. Proper staging of content from development to production must also be possible. Full UAT or QA environment are not very useful for threat detection, as it's very hard and expensive to replicate the telemetry flowing through production systems just for testing. But the production tools can have embedded testing environments for content. The Securonix platform, for example, has introduced the Analytics Sandbox, a great way to test content without messing with existing production alerts and queues.
Effective requirements gathering processes. Software development is plagued by developers envisioning capabilities and driving the addition of new features. It's a well-known problem in that realm and they have developed roles and practices to properly move the gathering of requirements to the real users of the software. Does it work for detection content? I'm not sure. We see "SIEM specialists" writing rules, but are they writing rules that generate the alerts the SOC analysts are looking for? Or looking for the activities the red team has performed in their exercises? Security operations groups still operate with loosely defined roles and for many organizations the content developers are the same people looking at the alerts, so the problem may not be that evident for everyone. But as teams grow and roles become more distributed, it will become a big deal. This is also important when so much content is provided by the tools vendors or even content vendors. Some content does not need direct input from each individual organization; we do not have many opportunities to provide our requirements for OS developers, for example, but OS users requirements are generic enough to work that way. Detection content for commodity threats is similar. But when dealing with threats more specific to the business, the right people to provide the requirements must be identified and connected to the process. Doing this continuously and efficiently is challenging and very few organizations have consistent practices to do it.
Finally, embedding the toolset and infrastructure into DDLC to make it really DaaC. Here's where my post is very aligned to what Anton initially raised. Content for each tool is already code, but the setup and placement of the tools themselves is not. There's still a substantial amount of manual work to define and deploy log collection, network probes and endpoint agents. And that setup is usually brittle, static and detached from content development. Imagine you need to deploy some network-based detection content and find out there's no traffic capture setup for that network; someone will have to go there and add a tap, or configure something to start capturing the data you need for your content to work. With more traditional IT environments the challenge is still considerable, but as we move to cloud, devops managed environments, these pre-requisite setting can also be incorporated as code in the DDLC.

There's still a lot to make full DaaC and comprehensive DDLC a reality. But there's a lot of interesting stuff in this sense going on, pushed by the need for security operations to align with the DevOps environments in need to be monitored and protected. Check the Analytics Sandbox as a good example. We'll certainly see more like this coming up as we move closer to the vision of threat detection becoming more like software development.

NG SIEM?

noreply@blogger.com (Unknown) — Fri, 11 Sep 2020 19:00:00 +0000

An interesting result from changing jobs is seeing how people interpret your decision and how they view the company you’re moving to. I was happy to hear good feedback from many people regarding Securonix, reinforcing my pick for the winning car in the SIEM race.

But there was a question that popped up a few times that indicates an interesting trend in the market: “A SIEM? Isn’t it old technology?”. No, it is not. It may be an old concept, but definitely not “old technology”.

Look at these two pictures below? What do they show?

Both show cars. But can we say the Tesla is “old technology”? Notice that the basic idea behind both is essentially the same: Transportation. But this, and the fact they have four wheels, is probably the only thing in common. This is the same for the many SIEMs we’ve seen in the market in twenty or so many years.

Here is the barebones concept of a SIEM:

How this is accomplished, as well as the scale of things, have changed dramatically since ArcSight, Intellitactics and netforensics days. Some of the main changes:

Architecture. Old SIEMs were traditional software stacks running on relational databases and with big and complex fat clients for UI. Compare this with the modern, big data powered SaaS systems with sleek web interfaces. Wow!
Use cases. What were we doing with the SIEMs in the past? Some reports, such as “top 10 failed connection attempts” or some other compliance driven report. Many SIEMs had been deployed as an answer to SOX, HIPAA and PCI DSS requirements. Now, most SIEMs are used for threat detection. Reporting, although still a thing, is far less important than the ability to find the needle in the haystack and provide an alert about it.
Volume. SIEM sizing used to be a few EPS, Gigabytes exercise. With the need to monitor chatty sources such as EDR, NDR and cloud applications the measures are orders of magnitude higher. This changes the game in terms of architecture (cloud is the new normal) and also drive the need for better analytics; we can’t handle the old false positive rates with the current base rates of events.
Threats. It was so easy to detect threats in the past. It was common to find single events that could be used to detect malicious actions. But attacks have evolved to a point where multiple events may be assessed, in isolation and together as a pattern, to determine the existence of malicious intent.
Analytics. Driven by the changes to threats, volume and use cases, the analytics capabilities of SIEM have also changed in a huge manner. While old SIEMs would give us some regex capabilities and simple AND/OR correlation, modern solutions will do that and far, far more. Enriched data is analyzed with modern statistics and ML algorithms, providing a way to identify the stealthiest threat actions.

With all that in mind, does it still make sense to call these new Teslas of threat detection a “SIEM”? Well, if we still call a Tesla a car, why not keep the SIEM name?

However, differentiating between the old rusty SQL-based tool and the advanced analytics SaaS tools of modern days is also important. In my previous life as an analyst I would frequently laugh at the “Next Gen” fads created by vendors trying to differentiate. But I also have to say it was useful to provide a distinction between the old Firewall and what we now call NGFW. People know the implied difference in capabilities when we say NGFW. With that in mind, I believe saying NG-SIEM is not really a bad thing, if you consider all those differences I mentioned before. Sorry Gartner, I did it! :-)

So, old SIEM dead, long live the NG-SIEM? No, I don’t think we need to do that. But in conversations where you need to highlight the newer capabilities and more modern architecture, it’s certainly worth throwing the NG there.

Tesla owners can’t stop talking about how exciting their cars are. For us, cybersecurity nerds, deploying and using a Next-gen SIEM gives a similar thrill.

I'm Joining Securonix

noreply@blogger.com (Unknown) — Mon, 31 Aug 2020 19:44:00 +0000

I’m very happy to announce today I’m starting my journey with Securonix!

I’ve spent the last five years working as an industry analyst, talking to thousands of clients and vendors about their challenges and solutions on security operations. During this time I was able to identify many of common pain points and what vendors have been doing to address them. Some with success, some not much.

Helping clients as an analyst is a great job. It gives you tremendous visibility into their challenges. But it is also somewhat limited into how much you can help them. So I ended up with many ideas and things I’d like to do, but with no right channel to provide them.

That’s why I chose to join Securonix. Securonix has a great platform to deliver many capabilities that organizations need to tackle their threat detection and response problems. I first came into contact with Securonix before my Gartner life, and have been watching it grow and evolve since then. When we produced an UEBA solutions comparison, back in 2016, it was the best one of the batch. But it didn’t stop there.

A few years ago Gartner said SIEM and UEBA would eventually converge. Securonix didn’t miss the trend. Actually, it was one of the main drivers. UEBA vendors first appeared in the SIEM Magic Quadrant back in 2017. Securonix was already there as a Visionary. Actually it was the vendor with the most complete vision at that time. Since then it managed to improve its ability to execute, becoming one of the leaders in the space. It hasn’t missed the major trends since then, adding important capabilities and quickly adapting to offer a great cloud SIEM solution.

Good tools are extremely important to anyone who wants to make a dent on the incredible threat detection and response challenges we face. I’m excited to help with the evolution of the best security operations and analytics platform available today. You can watch this great journey here, , on Linkedin and on Twitter (@apbarros).

From my Gartner Blog - Goodbye!

noreply@blogger.com (Unknown) — Fri, 28 Aug 2020 15:32:00 +0000

I’m sadly writing this as my last Gartner blog post! I’m moving to a new challenge. After years as an analyst, I decided it was time to get closer to delivering the initiatives that have been the focus of my research.

I’m immensely grateful for my time with Gartner. It has been a great experience and I had the opportunity to work with many bright people. I leave a special thank you to my mentor and main co-author, my great manager (thanks boss!) and my KIL (“Key Initiative Leader”, internal Gartner lingo).

Working as a Gartner analyst gives you the opportunity to go through incredible experiences. During the past five years, I was able to:

Write groundbreaking research on my favorite topics in cybersecurity. It was very rewarding to find people out there building their strategic plans using some of my own words and adding the figures I drew to their slides.
Deliver presentations to full audience rooms in many different places in the world.
Provide advice to some of the major vendors in this industry, having very interesting conversations with their main executives.
Discuss challenges and solutions with clients from all over the world and from many different industries. You just can’t imagine the crazy types of challenges they are facing out there! From exotic legal requirements to some very particular business characteristics, I have had many memorable calls during these years.
Collaborate with very smart colleagues and have exciting (and, how can I say? “Lively”, maybe…) discussions about the future of cybersecurity.
Chair the Security Summit in Brazil for two years, working with amazing people and putting together unforgettable events. I will definitely miss the experience to prepare and deliver the opening keynote there!

What I will miss mostly is experiencing those moments when you hear your client saying things like “that was the best advice I’ve ever heard”. Those are the moments that give an analyst a clear view of their sense of purpose. I’m really grateful for being able to go through that as a Gartner analyst.

Thank you Gartner. Thank you my reader. And I hope you follow me back to my personal blog. I’ll still be there.

The post Goodbye! appeared first on Augusto Barros.

from Augusto Barros https://ift.tt/2EK5WLs
via IFTTT

From my Gartner Blog - New Research: Open Source Tools!

noreply@blogger.com (Unknown) — Fri, 17 Apr 2020 18:58:00 +0000

After finishing the wave of research that covered pentesting, monitoring use cases, SOAR and TI, I’m excited to start research for a net new document covering an exciting topic rarely covered in Gartner research: Open source tools! The intent is to look at the most popular open source tools used by security operations teams out there. Things like the ELK stack, Osquery, MISP and Zeek. What I’d like to cover in this new paper is:

Why is the tool being used? Why not a commercial alternative?
How is it being used? What is the role of the tool in the overall security operations toolset, what are the integrations in place?
How much effort was put to implement the tool? What about maintaining it?
Is it just about using it or is there some active participation on the development of tool as well?
What are requirements to get value from this tool? Skills? Anything specific in terms of infrastructure, or processes?

It is a fascinating topic, which bring a high risk of scope creep, so the lists of questions answered and tools covered are still quite fluid.

In the meantime, it would be nice to hear stories from the trenches; what are you using out there? Why? Was that picked just because it was free (I know, TCO, etc, but the software IS free….) ? Or is it a cultural aspect of your organization? Do you believe it is actually better than the commercial alternatives? Why?

Lots of questions indeed. Please help me provide some answers

The post New Research: Open Source Tools! appeared first on Augusto Barros.

from Augusto Barros https://ift.tt/2Kbxglh
via IFTTT

From my Gartner Blog - Developing and Maintaining Security Monitoring Use Cases

noreply@blogger.com (Unknown) — Thu, 09 Apr 2020 21:09:00 +0000

My favorite Gartner paper has just been updated to its 3rd version! “How to Develop and Maintain Security Monitoring Use Cases” was originally published in 2016 as a guidance framework for organizations trying to identify what their security tools should be looking for, and how to turn these ideas into signatures, rules and other content. This update brings even more ATT&CK references and a new batch of eye candy graphics! So much different than the original Visio built graphics!

This is the anchor diagram from the doc, summarizing our framework:

Some nice quotes from doc:

“Some organizations create too much process overhead around use cases — agility and predictability are required. Processes must not be too complex because security monitoring requires fast and constant changes to align with evolving threats.”

“The efficiency and effectiveness of security monitoring are directly related to the appropriate implementation and optimization of the right use cases on the right security monitoring tools.”

“Do not simply enable everything that comes with the tools. A considerable part of that content may not be aligned with the organization’s priorities, or may not be applicable to its environment.”

“Make use case development similar to agile software development by being able to quickly implement or modify a use case to adapt to changing threat and business conditions.”

I hope you enjoy it, and let me know if you have the framework implemented in your organization. Please don’t forget to provide feedback about the paper here.

Next wave of research is about Open Source tools for threat detection and response, in parallel with interesting stuff on Breach and Attack Simulation.

The post Developing and Maintaining Security Monitoring Use Cases appeared first on Augusto Barros.

from Augusto Barros https://ift.tt/2JQhigf
via IFTTT

From my Gartner Blog - New Research on Threat Intelligence and SOAR

noreply@blogger.com (Unknown) — Tue, 31 Mar 2020 20:01:00 +0000

Since my blogging whip was gone I haven’t been posting as frequently as I’d like, but I realized we had recently published new versions of some of our coolest research and I completely missed announcing them here! So let me talk a bit about them:

The first one is a big update to our Threat Intelligence research, conducted by Michael Clark. The paper now is called “How to Use Threat Intelligence for Security Monitoring and Incident Response”. It has a more specific scope and is more prescriptive in its guidance, providing a nice framework for those planning to start using TI on their detection and response processes:

The other one is a refresh on our paper about SOAR – Security Orchestration, Automation and Response, conducted by Eric Ahlm. It provides an overview of SOAR and how to assess your readiness for this technology according to your use cases:

I hope you enjoy the new papers. I’m also working on an update to my security monitoring use cases paper, it will hit the streets soon. Meanwhile, feel free to provide feedback about the papers above here.

The post New Research on Threat Intelligence and SOAR appeared first on Augusto Barros.

from Augusto Barros https://ift.tt/2JzgjAV
via IFTTT

From my Gartner Blog - Updated Paper on Penetration Testing and Red Teams

noreply@blogger.com (Unknown) — Wed, 29 Jan 2020 18:36:00 +0000

I finally managed to publish the update to my paper on pentesting, “Using Penetration Testing and Red Teams to Assess and Improve Security”. It has some small tweaks from the previous version, including some additional guidance around Breach and Attack Simulation tools role.

Questions about how to define the scope of penetration tests are very common in my conversations with clients. I always tell them it should be driven primarily by their objective for running the test. Surprisingly, many have problems articulating why they are doing it.

The discussion about comparing pentests with other forms of assessments is there too, although we also published a paper focused on the multiple test methods some time ago.

A few good pieces from the document:

“Research the characteristics and applicability of penetration tests and other types of security assessments before selecting the most appropriate one for the organization. Select a vulnerability assessment if the goal is to find easily identifiable vulnerabilities.”

“Definitions for security assessments vary according to the source, with a big influence from marketing strategies and the buzzword of the day. Some vendors will define their red team service in a way that may be identified as a pentest in this research, while vulnerability assessment providers will often advertise their services as a penetration test. Due to the lack of consensus, organizations hiring a service provider to perform one of the tests described below should ensure their definition matches the one used by the vendor”

“Pentests are often requested by organizations to identify all vulnerabilities affecting a certain environment, with the intent to produce a list of “problems to be fixed.” This is a dangerous mistake because pentesters aren’t searching for a complete list of visible vulnerabilities.”

Next on the queue is the monitoring use cases paper. That’s my favorite paper and excited to refresh it again. You’ll see it here soon!

The post Updated Paper on Penetration Testing and Red Teams appeared first on Augusto Barros.

from Augusto Barros https://ift.tt/2Gx5wWq
via IFTTT

From my Gartner Blog - The New Vulnerability Management Guidance Framework

noreply@blogger.com (Unknown) — Fri, 25 Oct 2019 20:51:00 +0000

After a huge delay I can finally announce that the new version of our Vulnerability Management Guidance Framework is out! Although it is a refresh of a document that has gone through many updates (even before my Gartner time), this one has some very nice new stuff to mention. First, we refreshed our VM cycle and it’s closer to the reality of most organizations now:

This versions includes a revamped prioritization section, as well as some additional content on vulnerability assessment options. In the past we left most of the VA content for another document, but now it’s back to the VM guidance.

Some interesting pieces of this version:

One of the most common ways to fail at VM is by simply sending a report with thousands of vulnerabilities to the operations team to fix. Successful VM programs leverage advanced prioritization techniques and automated workflow tools to streamline the handover to the team responsible for remediation.
Organizations adopting DevOps practices must adopt an approach integrated to continuous integration/continuous delivery (CI/CD) cycles and addressing issues at preproduction stages.
Include the identification of underlying issues as one of the main objectives of the VM process. Although it is still important to find and address individual vulnerabilities, VM should also provide insight into areas that need to be improved in the organization’s security posture.
[On VA scanning frequency] The ultimate frequency goal should reflect the value of providing refreshed vulnerability data to consumer processes, such as patching and security monitoring. If those processes will not benefit from more frequent scans, there is really no point in trying to achieve a higher frequency.
Mitigation can often be the first line of defense, especially if it can be implemented quickly. However, mitigated vulnerabilities are not gone. They still need to be fixed eventually.
All exceptions must have an expiration date. Do not allow indefinite exceptions.

In general, it’s a far clearer document and easy to read now. Thanks Anna Belak for your magical wordsmithing powers!

We are always looking for detailed feedback on our papers. Feel free to drop some comments here if you read the doc.

The post The New Vulnerability Management Guidance Framework appeared first on Augusto Barros.

from Augusto Barros https://ift.tt/2JlGOKL
via IFTTT

From my Gartner Blog - Our New Research on Incident Response Has Been Published

noreply@blogger.com (Unknown) — Tue, 15 Oct 2019 17:33:00 +0000

We finally managed to publish our great new (in fact, refreshed) document on preparing for incident response, “How to Implement a Computer Security Incident Response Program”.

This is the first document of my colleague Michael Clark, who did a terrific job of modernizing some stuff from a long time ago.

Some interesting pieces from this guidance document:

Organizations that practice their incident response program find gaps and areas for improvement. Certain exercises also make the computer security incident response team (CSIRT) more comfortable and better equipped when an incident occurs.

Include all the locations and services where your assets and data reside in the plan. This includes SaaS and company-controlled cloud assets. Many high-profile breaches involve elements outside the organization’s perimeter

Detections that must be addressed are inevitable. Organizations are often forced into a response mode by attackers and third-party breach notifications.

As usual, we are always looking for detailed feedback on our papers. Feel free to drop some comments here if you read the doc.

The post Our New Research on Incident Response Has Been Published appeared first on Augusto Barros.

from Augusto Barros https://ift.tt/2IRhDza
via IFTTT

From my Gartner Blog - Presenting at the Gartner Security and Risk Management Summit DC 2019

noreply@blogger.com (Unknown) — Mon, 17 Jun 2019 04:21:00 +0000

This is literally a last minute blog post about my sessions at this year’s Gartner Security and Risk Management Summit. This time I have three sessions:

Tuesday 18, 2:30PM – Debate: Changing Societal Perception of Cybersecurity: This is a very fun debate with my colleague Paul Proctor, where we discuss the need to change society’s perception of security. Paul is trying his best, but I don’t think he can win this one

Wednesday 19, 5:15PM – Creating Security Monitoring Use Cases With the MITRE ATT&CK Framework: The MITRE AT&CK framework has quickly become a popular tool for many security operations practices. This session illustrates how it can be used to address some of the most common challenges of security operations centers: How to create security monitoring use cases? How do we know if we are looking for right things? What should be the starting list of use cases on our SIEM deployment?

Thursday 20, 10:45AM – Further Evolution of Modern SOC: Automation, Delegation, Analytics: This presentation provides a structured approach to plan, establish and efficiently operate a modern SOC. Gartner clients with successful SOCs put the premium on people rather than process and technology. People and process overshadow technology as predictors for SOC success or failure. Among other things, it will cover questions such as: Do I need a SOC and can I afford it? Where can I rely on automation and where do I need to outsource or delegate? Can SOAR tools really automate my SOC?

This is one of the most fun weeks of the year for us Gartner analysts. For you attending the event and the sessions above, please let me know if you like them, what could the different and how we can improve.

The post Presenting at the Gartner Security and Risk Management Summit DC 2019 appeared first on Augusto Barros.

from Augusto Barros https://gtnr.it/2Im4DSs
via IFTTT

From my Gartner Blog - Considering Remediation Approaches For Vulnerability Prioritization

noreply@blogger.com (Unknown) — Thu, 02 May 2019 22:34:00 +0000

As Anton said, we are starting our work on vulnerability management this year. One of the points I’ve started to look at more carefully is how much the different patching approaches can affect how we prioritize vulnerabilities for remediation.

Expanding the prioritization of vulnerabilities to go beyond CVSS and include threat context is something we are seeing quickly moving to mainstream. Now it’s not uncommon to see organizations that don’t only look at how bad a vulnerability could be, but how much it is and even will be (great work on prioritization models by some vendors out there). This really helps reducing the noise and focus on what matters.

But this is helpful when you look at vulnerabilities individually only. When they move to other side of the fence, however, the problem has some different nuances. IT operations don’t see vulnerabilities, they see patches. And the relationship between patches and vulnerabilities are not always one-to-one, and not all patches are equal. There are those “applied-periodically-automatically-with-no-intervention” types of patches, there are also the “almost-never-released-and-when-installed-breaks-everything” types of patches. The IT Ops team may not even bother looking at the priority of the former but may want a very thorough justification for why they need to apply the latter.

Many vulnerability management programs, because they are managed by the security team, do not consider the characteristics of the patching process when applying their prioritization criteria. But if they want to be taken seriously by IT Ops, they should. So, my questions here are:

– When you prioritize vulnerabilities, do you incorporate “cost to patch” in your criteria?

– If you do so, how? Does your tool set allow you to do it? Where is that information coming from?

– If you define patching times by categories, have you considered patching characteristics for categorization? For example, do you define categories as something like “non-critical workstations” or like “windows workstations with auto-updates on”?

– Do you look at the vendors of software deployed in your environment as part of this exercise? Patching Microsoft vs. Oracle, for example? Do you take into consideration the quality of the patches or release schedule of the vendor to define the patching times?

We like to stay away from the patching problem as it seems more like an IT operations problem than a security problem. But I believe that proper prioritization (or at least one that will be useful for the goal of fixing vulnerabilities) should include something about the required patches too. If that’s correct, what are the tools available for that and how are organizations doing it?

Please jump in and leave your experiences in the comments section!

The post Considering Remediation Approaches For Vulnerability Prioritization appeared first on Augusto Barros.

from Augusto Barros https://gtnr.it/2VcMTAS
via IFTTT

From my Gartner Blog - The Deception Paper Update is Out!

noreply@blogger.com (Unknown) — Fri, 22 Feb 2019 17:07:00 +0000

Good thing about when Anton is away is I’m always able to jump and announce our new research ahead of him

So, the update to our “Applying Deception Technologies and Techniques to Improve Threat Detection and Response” paper has finally been published. This is a minor update, but as with every updated paper, it has changed for better. Some of the highlights

New, and more beautiful pictures (thanks to our co-author Anna Belak for making our papers look 100% better on the graphics side!)
Additional guidance on how to test deception tools (tip: put your Breach and Attack Simulation tool to use!)
A better understanding on how the Deception Platforms are evolving and what are the current “must have” features you’ll find there

We also tuned key findings and recommendations, including these:

Evaluate deception against alternatives like NTA, EDR, SIEM and UEBA to detect stolen-data staging, lateral movements, internal reconnaissance and other attack actions within your environment.
Deploy deception-based detection approaches for environments that cannot use other security controls due to technical or economic reasons. Examples include IoT, SCADA, medical environments and highly distributed networks.

We are also working on a solutions comparison on this area. A lot of exciting stuff on that one, stay tuned. Meanwhile, please check the new paper and don’t forget to provide feedback!

The post The Deception Paper Update is Out! appeared first on Augusto Barros.

from Augusto Barros https://ift.tt/2Xjdgm8
via IFTTT

From my Gartner Blog - More on “AI for cybersecurity”

noreply@blogger.com (Unknown) — Fri, 04 Jan 2019 18:34:00 +0000

There is a very important point to understand about the vendors using ML for threat detection.

Usually ML is used to identify known behavior, but with variable parameters. What does that mean? It means that many times we know what bad looks like, but not how exactly it looks like.

For example, we know that data exfiltration attempts will usually exploit certain protocols, such as DNS. But data exfiltration via DNS can be done in multiple ways. So, what we do to detect it is to use ML to learn the normal behavior, according to certain parameters. Things like amount of data on each query, frequency of queries, etc. Anomalies on these parameters may point to exfiltration attempts.

On that case ML helps us find something we already know about, but the definition is fuzzy enough that prevents us from using simple rules to detect it. This is an example of unsupervised ML used to detect relevant anomalies for threat detection. There are also many examples of using supervised ML to learn the fuzzy characteristics of bad behavior. But as you can see, a human had to understand the threat, how it operates, and then define the ML models that can detect the activity.

If you are about to scream “DEEP LEARNING!”, stop. You still need to know what data to look at with deep learning, and if you are using it to learn what bad looks like, you still need to tell it what is bad. We ended up at the same place.

Although ML based detection is a different detection method, the process is still very similar to how signatures are developed.

What haven’t been done yet is AI that can find threats not defined by a human. Most vendors use misleading language to lead people to think they can do it, but that doesn’t exist. Considering this reality, my favorite question to these vendors is usually “what do you do to ensure new threats are properly identified and new models developed to identify them?”. Isn’t that interesting that people buy “AI” but keep relying on the human skills from the vendor to keep it useful?

If you are a user of these technologies, you’ll usually need to know what the vendor does to keep what the tools looks for aligned to new threats. For the mature shops, you also need to know if the tool allows you to do that yourself, if you want/need.

That’s a good way to start the conversation with a “Cybersecurity AI” vendor; see how fast they fall into the trap of “we can find unknown unknowns”.

The post More on “AI for cybersecurity” appeared first on Augusto Barros.

from Augusto Barros https://gtnr.it/2AwXE4H
via IFTTT

From my Gartner Blog - The new (old) SIEM papers are out!

noreply@blogger.com (Unknown) — Tue, 13 Nov 2018 18:41:00 +0000

As Anton already mentioned here and here, our update of the big SIEM paper was turned into two new papers:

How to Architect and Deploy a SIEM Solution
SIEM is expected to remain a mainstay of security monitoring, but many organizations are challenged with deploying the technology. This guidance framework provides a structured approach for technical professionals working to architect and deploy a SIEM solution.
Published: 16 Oct 2018
Anton Chuvakin | Anna Belak | Augusto Barros

How to Operate and Evolve a SIEM Solution
Managing and using a SIEM is difficult, and many projects are stuck in compliance or minimal value deployments. Most SIEM challenges come from the operations side, not broken tools. This guidance supports technical professionals focused on security working to operate, tune and utilize SIEM tools.
Published: 05 Nov 2018
Augusto Barros | Anton Chuvakin | Anna Belak

We decided to split the document so we could expand on those two main activities, deploying and operating a SIEM, without the worry of building a document so big it would scare away the readers. A great secondary outcome of that is we were able to put together separate guidance frameworks for each one of those activities. Some of my favorite pieces of each doc:

Deploy

“User and entity behavior analytics (UEBA)-SIEM convergence allows organizations to also include UEBA-centric use cases and machine learning (ML) capabilities in their deployment projects.” (A hype-less way to talk about “OMG AI AI!”)

“Staff shortages and threat landscape drive many organizations to SaaS SIEM, co-managed SIEM and service-heavy models for their SIEM deployments and operation.” (Because, in case you haven’t noticed, SIEM NEEDS PEOPLE TO WORK)

“Adopt the “output-driven SIEM” model, where nothing comes into a SIEM tool unless there is a clear knowledge of how it would be used.” (I know it’s old, but hey, this is our key advice for those deploying SIEM! So, still a favorite)

“Deploy use cases requiring constant baselining and anomaly detection, such as user account compromise detection, using ML/advanced analytics functions previously associated with UEBA” (because it’s not all marketing garbage; these use cases are the perfect fit for UEBA capabilities)

Operate

“Creating and refining security monitoring use cases is critical to an effective SIEM. User-created and customized detection logic delivers the most value.” (because ongoing SIEM value REQUIRES use case management)

“Develop the key operational processes for SIEM: run, watch and adapt. When necessary, fill the gaps with services such as MSS and co-managed SIEM” (we promoted “tune” to “adapt”)

“Prepare and keep enough resources to manage and troubleshoot log collection issues. New sources will be added; software upgrades change log collection methods and formats; environment changes often cause collection disruption.” (ML capabilities, big data tech, all that is cool, but a big chunk of SIEM work is still being able to get the data in)

The post The new (old) SIEM papers are out! appeared first on Augusto Barros.

from Augusto Barros https://ift.tt/2OEUctf
via IFTTT