Responsible Response
Responsible disclosure is one thing, but how do you respond when you're informed of a possibly compromised machine or vuln in your apps?
2:50 PM -- Ever received a security incident or vulnerability notification from someone outside your company? That could be an IDS alert they saw generated by a host on your network communicating with a host on theirs, or a vulnerability in your Website or in one of your products.
How do you respond? Or do you respond at all?
If it's a compromised machine attacking others, your response should be very simple and immediate: Follow your standard incident response procedures, and send a message back that it has been handled. Having been the recipient and sender of notifications over the years, I know that responding quickly is appreciated by both parties involved. In some situations, it's even more important because it can lead to uncovering additional issues.
On two separate occasions, I received notification about a machine on my network attacking other machines. After analyzing the information sent to me and correlating data in my logs, it turned out that my machine was not actually compromised but instead responding to attacks generated by the hosts on the network of the person who notified me. The administrator never bothered to do in-depth analysis, so I'm sure they felt a little foolish when they got my response.
Vulnerability notifications about applications are a bit stickier because they usually require significantly more work. Website vulnerabilities are usually the easiest to fix unless the vulnerability is in an internally developed Web application. But the likelihood of receiving those are low because the researcher who found the vulnerability is more likely to contact the application developer.
As an application developer, one of the worst experiences is finding out about a bug in your app through the Bugtraq or Full Disclosure mailing lists. There has been plenty of debate in the security community about responsible disclosure and full disclosure, but much of the responsibility also falls upon the developer to respond quickly and appropriately. Taking the stance that you won't work with "hackers" is irresponsible to both the researcher who discovered the vulnerability and to your customers.
How would your customers feel if they knew you refused to work with a researcher who had discovered a vulnerability, so he then released the information publicly, resulting in your customers getting compromised? If you don't have a policy on how to deal with notifications, take the time to sit down with management and developers to determine what is reasonable. Involving everyone is important to ensure that you do the right thing.
– John H. Sawyer is a security geek on the IT Security Team at the University of Florida. He enjoys taking long war walks on the beach and riding pwnies. When he's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading
About the Author
You May Also Like
DevSecOps/AWS
Oct 17, 2024Social Engineering: New Tricks, New Threats, New Defenses
Oct 23, 202410 Emerging Vulnerabilities Every Enterprise Should Know
Oct 30, 2024Simplify Data Security with Automation
Oct 31, 2024Unleashing AI to Assess Cyber Security Risk
Nov 12, 2024