Faulty Security Control Logic
Just because a security control has a potential attack vector doesn’t make it useless
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.
🔒 Related Stories: Cloud Governance | Cybersecurity | Secure Code | Application Security
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*e0RkZ3RNYqkoUwiWjDmF7w.png)
I want to address something I keep reading regarding security controls and attack vectors.
Saying just because something might be abused via a particular attack vector means you shouldn’t use it is faulty logic.
I’ll give you an example. I’ve heard people say, “Oh no! Firewalls can be bypassed with tunnels. WAFs are useless because SSRF attacks!”
Well yes, various security controls can be bypassed by certain attacks, but that doesn’t mean they are irrelevant and useless against all attacks. A firewall can still block ports from any access or connections at all, and that is the point.
I wrote in my book how blocking 445 from being accessible from the Internet would have saved everyone attacked by the WannaCry ransomware. That includes the hospitals who had to stop admitting patents as a result of ransomware infiltrating their networks.
Although a more crafty attack might have been able to tunnel through the firewall in a sneakier manner, the attacker didn’t need to — because people just left ports exposed to the Internet that should have been restricted to private networks.
Firewalls stop attacks.
Firewalls don’t stop all attacks.
A firewall might not stop the type of ICMP tunneling I wrote about in my analysis of the Target Breach. Attackers exfiltrated data and sent commands via the ICMP protocol. You know, ping. If you need to allow ICMP your firewall might be susceptible to that fate. Attackers have also been known to exfiltrate data using DNS or perform attacks using ip options, NTP, or packet fragmentation. If an attacker can attack your web application via a valid channel then yes, your firewall will not help in that case because you need to allow the Internet to access port 443 and send responses.
There are other security controls for those attacks.
Actually, limiting your DNS traffic to specific DNS servers might help with DNS exfiltration as well as crafting your firewall rules to only allow certain ICMP types and codes. As for your application, a firewall might even help for certain web-based attacks, but yes, you likely need additional controls for that scenario. A penetration test might help.
Just because a particular security control is not foolproof doesn’t mean you should not use it. Security architecture never depends on one control. That’s why you need security architects who understand how all your controls work together.
This same case of faulty logic applies to the arguments that people misconfigure a security control all the time therefore we shouldn’t use it. Or that security control is hard, therefore we shouldn’t use it. What is the alternative? A data breach because something is too complicated or takes time? I wrote about that here:
Rather than saying something is hard or misconfigured or attacks exist so we shouldn’t use it — address the actual problem.
- How can you make it easier without losing protection?
- How do you prevent misconfigurations?
- How do you address the gap that exists due to a particular attack vector without throwing away other protections?
The ultimate question is — will your change make it easier for attackers to infiltrate your systems? If you give up on a control because it has a particular attack vector, how many other attack vectors have you introduced that didn’t exist when you had that control in place?
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2023
The best way to support this blog is to sign up for the email list and clap for stories you like. That also helps me determine what stories people like and what to write about more often. Other ways to follow and support are listed below. Thank you!
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
Author: Cybersecurity for Executives in the Age of Cloud
Presentations: Presentations by Teri Radichel
Recognition: SANS Difference Makers Award, AWS Security Hero, IANS Faculty
Certifications: SANS
Education: BA Business, Master of Software Engineering, Master of Infosec
Company: Cloud Penetration Tests, Assessments, Training ~ 2nd Sight Lab
Like this story? Use the options below to help me write more!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Clap
❤️ Referrals
❤️ Medium: Teri Radichel
❤️ Email List: Teri Radichel
❤️ Twitter: @teriradichel
❤️ Mastodon: @[email protected]
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
❤️ Buy a Book: Teri Radichel on Amazon
❤️ Request a penetration test, assessment, or training
via LinkedIn: Teri Radichel
❤️ Schedule a consulting call with me through IANS Research
My Cybersecurity Book: Cybersecurity for Executives in the Age of Cloud
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/0*H9Ew1KCl-29nZiPR.jpeg)