Kevin Beaver, CISSP is an independent information security consultant, writer, and professional speaker with Atlanta, GA-based Principle Logic, LLC.
With over 33 years in IT and 27 years in security, Kevin specializes in vulnerability and penetration testing, security program reviews, and virtual CISO consulting work to help businesses uncheck the boxes that keep creating a false sense of security.
He has written 12 books on security including the best-selling Hacking For Dummies and The Practical Guide to HIPAA Privacy and Security Compliance. Kevin has written over 1,300 articles on security and regularly contributes to TechTarget’s SearchSecurity.com and Ziff Davis’ Toolbox.com.
He has a bachelor’s in Computer Engineering Technology from Southern College of Technology and a master’s in Management of Technology from Georgia Tech. In his free time, Kevin enjoys road racing his Mazda Miata in the Spec Miata class with the Sports Car Club of America (SCCA), riding dirt bikes, and snow skiing.
Who owns the responsibility of the software development lifecycle (SDLC) in your business? It’s easy to assume, through a traditional lens, that the CEO and/or Board of Directors might ultimately be responsible for what takes place throughout the SDLC
For some time now, public companies in the United States have been on notice that the Securities and Exchange Commission (SEC) is tightening down on the reporting of security incidents. Now that the compliance deadlines are here, it seems a bit more real. As a complement to my recent webinar "SEC Cybersecurity Ruling: Application security + incident response" this piece serves as a recap and a checklist on what businesses – both public and private – need to be focusing on now that the SEC disclosure rules are here.
This year’s RSA Conference was full of the latest and most excellent tools and tips for improving information security in the enterprise. I specifically sought out topics related to application security, and the sessions didn’t disappoint. It was nice to hear about emerging tools and the importance of not ignoring the basics. The latter is something that I have been evangelizing for decades, and it’s good to see that it’s finally getting traction, especially in the application security space.
Web API endpoints have a relatively small footprint compared to the overall web application environment. Still, they provide an entry point into critical parts of the application that can let attackers interact and manipulate things for ill-gotten gains. Some API exploits can facilitate attacks against users. Others can lead to full compromise of the web environment.
The Open Web Application Security Project (OWASP) Top 10 is a consensus list of the top web application security concerns, guiding testers and developers. The 2021 version includes new categories and relabelled items, providing a great resource for application security and audit/compliance. Leverage the OWASP Top 10 to spread awareness and make sure you don't miss out on anything.
SAST has its place, DAST is great at finding the majority of flaws that the bad guys are going to uncover, and IAST offers unique approaches to complex situations. At a minimum, DAST should be your main focus. Step back and consider your application environment, your internal resources and expertise, as well as your budget.
When every security flaw is deemed important, it creates chaos at the business level. In the short term, precious resources are wasted addressing such findings. Longer-term, these things add up to create true dysfunction in an overall security program which, ironically, makes the organization more susceptible to the risks that matter.
Shift left security incorporates security and testing phases at the earliest stages in SDLC, which can be done by integrating security testing in CI/CD pipelines.
