Cody Richardson

Detecting and preventing the effects of phishing emails has become a primary interest for enterprises and governments today. Often because phishing emails lead to network breaches, ransomware, and exfiltration of sensitive information. Patching vulnerabilities, ensuring AV/EDR/XDR is installed on endpoints, network segmentation, and MFA are all great to do, but one step we can take before relying on these measures is ensuring the end-user community is routinely educated on how to detect phishing emails.  So how do we detect phishing emails? Screening Emails Here are some of the items on what I call my "initial phishing screening checklist": Sender name and email address (especially domain) that doesn't match a legitimate one. Statements urging me to act quickly. Was I expecting an email like this? If I know the person and/or can reach them by phone, can I confirm it is them truly sending the email? (Out-of-band communication).  At least on this one they give 24 hours not

In terms of security, we've come a long way since the days of Windows XP. Even compared to your typical Windows 7 Enterprise install just a few years ago there have been huge security advancements in the industry and specifically within Windows. Here is an overview of some of those improvements, and if this series is popular enough, I may do a deep-dive on some of the individual features in the future. Secure Boot Before ransomware became the go-to malware for bad actors, one of the popular, more sophisticated pieces of malware was the rootkit. This allowed code to be run in kernel mode within Windows effectively bypassing most antivirus software installed on the system. This also meant being capable of performing almost anything on the system without issue. To mitigate this issue something was needed to verify that the bootloader run before Windows was legitimate. This is where Secure Boot fits into the Windows Security picture (though Secure Boot works with macOS and Linux comput

Often in infosec we get caught up on CVEs, the latest breach, or ransomware. Unfortunately, the other half of the job (project management, documentation, etc) can sometimes get less attention. Admittedly, they don't make movies about completing the paperwork after most action films. But in the real world it's what can lose court cases or certify a company as compliant with a government regulation.  We all wish documentation was clearer when reading it but very few enjoy writing it. I'm going to paint a broad brush here and put them all into two categories: Formal technical documentation E.g. SOC reports, company policies, SIG assessments, etc. Informal technical documentation E,g, the internal (or even customer facing) documentation explaining a concept or how to complete a technical task such as updating the OS version on a firewall. I'm not a Technical Writer, but I don't find writing documentation as painful as some, and I appreciate coming across what I find to