I wanted to clarify some complex topics regarding the Exchange / ProxyLogon discussions that happened since the dust has settled.
1. I'm concerned generally about the negativity against security researchers releasing code as I view this as taking steps back not forward.
1/10
2. I think researchers should be mindful of when a PoC drops. In the ProxyLogon event, I was against dropping early to give companies time to patch. In stating that, there should be no hindrance as to when a researcher publishes code, especially after a patch is released.
2/10
3. My biggest fear is we are moving back to where red is secretive in TTPs which does not help the industry progress forward. This occurred several years ago in this industry, and there were several years of organizations not understanding how to defend themselves.
3/10
4. We've made a lot of strides, both due to blue and red working together collaboratively. To me, this is likely the only path to continued success and always having the betterment of organizations and security in mind first.
4/10
5. I think everyone has their own perspectives/views on this, and it's a very complex topic. Do you release a PoC after a patch has been released knowing that there are organizations that may never patch or are extremely slow.
5/10
6. The PoC which was first released was intentionally broken and required a significant understanding in order to make it work. This allowed researchers all around the world and defenders to piece together the entire attack chain and help better serve organizations impacted. 6/10
7. I saw this first hand at #TrustedSec where the red team and IR teams worked as one unit as information wasn't readily available out there since it was so new. That collaboration is key during situations like this.
7/10
There's a balance between responsibly releasing PoCs, OSTs, and others that we should always be mindful of.
As offensive testers, trying to simulate threat models of real-world adversaries, it's paramount that we model the same types of attacks in order to best defend.
8/10
As defenders, we need to understand real-world attacks against our organization or have prior breach data.
As offense, we need to have the tooling and capabilities to simulate/emulate. We can still do that responsibly and wait a bit, giving time for orgs to address.
9/10
My parting thoughts here is that we shouldn't be negatively going after researchers for their work and effort. It's needed, and it's something that will continue to make us better as an industry. Like other roles, we all make up an ecosystem built on making things better.
10/10
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Last week, made a comment about how I wasn't a huge fan of Sentinel overall. Got to dive a bit deeper into it with my team over at Binary and has definitely changed my perspective a bit.
Sentinel is not easy by any stretch but there is a lot to it.
If you have the right data going into it (which isn't easy), and you have a team behind you to build up the detections, Sentinel is extremely powerful.
With jupyter and KQL foundation is super powerful to build what you need to off of it.
From my comments earlier, it is a solid product.. It just requires a substantial lift to get it to a point that will help you mature monitoring and detection capabilities.
Requires a knowledgeable team is the biggest thing there.
Unpopular opinion: The more I dive into Azure Sentinel, the less I'm impressed. For SMBs it's OK for commodity alarms due to the simplicity of O365 logs and others, but customized alarms, threat hunting, etc. is very difficult.
I do like KQL, but it's not even close to others.
Using Sentinel as a method for increasing coverage and effectiveness of TTPs would be difficult for an organization other than commodity attacks.
I do want to state that Microsoft is by far stepping up the game all around and very noticeably.
This isn't a gripe about anyone at all. Some amazing folks there working hard.
I'm just providing my experiences with Sentinel, and just not impressed.
Client: Why didn't nextgen EDR pick any of this up?
Us: Detection is more than just an EDR, it requires an understanding of your network.
Client: Can you get on phone with the vendor to share all of your TTPs so they can detect?
We're working with the customer to help educate and shore up the deficiencies, but it's just rough because of the over-reliance on security tools versus baselining and doing the work for your own environment.
This also isn't just a CustomerX problem. It's a widescale industry problem in general. There is no solution out there that does the hard work of building a security program or focusing on your threat models and baselining your own infrastructure.