added notes_from_blackhat_2022.md

notes/notes_from_blackhat_2022.md

@@ -0,0 +1,30 @@
+## 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.
+#### 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](https://github.com/package-url/purl-spec) 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](https://www.youtube.com/watch?v=qtl0xA1eVPM)
+#### Open Source Vulnerability Database
+[osv.dev](osv.dev) This database is super awesome and they have a great [schema](https://ossf.github.io/osv-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 for no reason. 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](https://git.mcdevitt.tech/bpmcdevitt/data_importer/-/blob/main/doc/cna_readme_notes/cnas_with_html_advisories.md) 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.