security_tools/notes/notes_from_blackhat_2022.md

Notes from Blackhat:

Some of the thoughts that I have on my recent Defcon/Blackhat experience.

Main Goal:

I wanted to try to focus on going into Blackhat and Defcon with learning more about the software security advisory ecosystem and if there could be improvements upon using CPE for matching logic to vulnerabilities.

Vendor Booth Impressions:

Compared to last year, the first year that I have attended both during COVID, there were far more people this time around. I went around the vendor booth areas a good number of times and just tried to observe and take note of some of the companies and the general ideas that tthey were trying to all potray. I am mostly numb to vendor marketing hype or salespeople so I just walked around and observed vendors giving presentation to others and tried to read the names. Some concepts in general that i noted:

• saw many buzzwords. SBOM, Risk-Based, Zero-Trust. It's pretty cool to have been apart of Kenna as we pioneered much of the Risk-Basked vulnerability management concepts. It is interesting to take note of how Risk-Based focus on remediation has driven much of the focus.
• SBOM was a heavy one that i saw alot of. CISA is doing a great job spreading the awareness, at least judging the amount of time I saw this as a concept focused on. Even from many of the innovation booths, you would see alot of mention of SBOM.
• Another thing that I saw some of this time was MITRE ATT&CK framework being mentioned. It seems like there are a good number of initiatives out there trying to map the ATT&CK Framework back to their software so they can focus on behavioral based threat monitoring
• There were alot of red team / pentest services. That still seems like a space where there is alot of room for experimentation and it was cool to see some of the startup companies. But some of the companies you really have to look at them with a close eye because often they are repackging existing solutions/programs.

Concepts that I learned about:

SBOM

Software Bill of Materials. CISA has been pushing it for about a year or maybe a little bit more now. This is basically a list of an inventory of software, the version numbers, ecosystems, their dependencies. An entire trail of what is actually installed on this system. You can't secure something without knowing exactly what is inside of it. There are weird edge cases that have come up in the recent past IE log4j log4shell vulnerabilities that go a little bit deeper into what is required to determine vulnerability or not. These two urls have all the goto: resources for deep-diving SBOM:

• cisa
• ntia

VEX

Vulnerability exploitability exchange. This can be thought of as a machine-readable security advisory. There is alot of documentation about this one, and I need to learn about it further.

Package-url (PURL)

CPE has its limitations and package-url can be an open standard that can improve upon it, or a better way to probably think about it is a way to supplement/enhance on top of CPE. It was vetted by some of the people who wrote HTTP and its a url. A great introduction to it can be found here

Open Source Vulnerability Database

osv.dev This database is super awesome and they have a great schema. I am going to start contributing to this database to help strengthen the ecosystem further. By having this database be open source, all of the companies and vendors can finally start to work together and we can work at a pace that each individual is comfortable at. I think alot more work can get done this way and we can build a great vulnerability database together out in the open. Everyone will benefit from this. It uses PURL package-urls instead of CPEs and goes directly to the advisory if their is a machine readable version. The more advisories that can get converted to this schema format, the quicker this database can get adapted across the entire security ecosystem so everybody is not all solving the same solution in their own closed ecosystems. We all want the same thing, to secure the systems, and this is a great way to approach it.

Vulnerability Scanners

I did not see much on Microsoft based scanners, other than the Microsoft booth who were marketing their Endpoint software. Which for Windows based stuff works great, but I have also recently learned that it does work well for Linux based systems too. Overall the Microsoft vuln scanner is really good and I would love to get it in an enviroment to test it out further.

• Grype: Go based. Container and filesystem scanner. Works great with SBOMS. Kind of takes its input from SYFT SBOMS. Similiar to Trivy. I will be reading much of the source code to learn Go and understand more about how to do SBOMs.
• Syft: Go based. This program is super cool. It generates SBOMS from a container or filesystem. I will be reading alot of this code too in the future to study it and figure out how to do SBOMs.

CSAF - Common Security Advisory Framework

This is a new standard being discussed around automating security advisories. As I noted here as one example, there are many security advisories from various CNA's that have only an HTML table of their advisory data. They are a victim of the times, and we used to interpret thigns via web browsers. But now we need a way to pass around the security advisory data so our scanners that we are all focusing on building can accurately and reliably consume the data so there is no time gap, and so things are standarized and so we dont have to scrape html. This is happening through OASIS. I want to see if I can maybe sit in on a meeting to see how they go and how close it is to being adopted.

Cool talks

Since I walked more than 50 miles that week lol I managed to only go to 2 talks at Blackhat. One of them was a lunch and learn panel with Allan Friedman from CISA and Ed Bellis, Jerry Gamblin, Michael Roytman from Kenna/Cisco, and Jay Jacobs from Cyentia Institute. The lunch and learn was great because that was where I heard about CSAF. And it was the first meal in vegas where I was able to eat purely vegan/vegeterian food. The meal was delicious and the talk was great!

The second talk that I attended was super interesting. It was by Brian Gorenc and Dustin Childs from Trend Micro/Zero Day Initiative. They are both super experts and the talk focused on how security advisories are ommitting data from the descriptions and just relying on CVSS alone and how thats not that great. I think I can see it from both perspectives, the vendor not wanting to give the exploiters information and the exploiters that can quickly write exploit code based on vuln descriptions. Both make sense, I'm not sure leaving out vuln details in the description though will be that effective and reducing exploits, hackers gonna hack yo. They also showed examples of vendor 'dud patches' and poor patches based on code from PoC. They showed how researcher often resubmits vulnerability (often the same or slight variation) because they figured out the patch is a dud pretty easily by reversing the code and seeing basically no differences. link_to_slides

I am for sure going to rewatch both talks when blackhat posts them online.

Conclusion

I think growing the osv.dev database is an important step. I am going to continue to try to learn more about VEX and try to see if I can potentially develop some tooling around it and/or write conversion programs that convert security advisories to osv-dev schema. CPEs are great for things like microsoft products and I am interested to see if they adopt it. I will try to look further into seeing what microsoft is doing about SBOMS because I am curious. Overall it was a good trip and I am glad that I went. I dont really like Las Vegas (at least the strip), and having to dodge drunk people sucked but it is what it is. Next time I go I will rent a car or motorbike and try to get out of the city maybe on one of the early days or in between talks to change it up a bit