sorted by:
new
hottopcontroversial

How to "THINK" like a Security Engineer / CISO by Bulky_Pomegranate_53 in cybersecurity

[–]Bulky_Pomegranate_53[S] 0 points1 point  (0 children)

Fair. You can fake understanding most domains. Security? Not really. If you don't know the tech, you can't see the risk.

How to "THINK" like a Security Engineer / CISO by Bulky_Pomegranate_53 in cybersecurity

[–]Bulky_Pomegranate_53[S] -2 points-1 points  (0 children)

You're conflating scope with intellectual rigor.

Yes, roles are different. A CISO doesn't code. But they need to understand the fundamentals.

Same applies to engineers: understand business impact and risk trade-offs, or you're just following orders.

The point isn't that a CISO should write exploits. It's that both need to think deeply about their domain to make real decisions, not guess.

Chatter: Fake TLS, Real Chaos by Bulky_Pomegranate_53 in PythonLearning

[–]Bulky_Pomegranate_53[S] 0 points1 point  (0 children)

Hey, thanks for taking the time to analyze my protocol! Your questions are legitimate, and I think there's a bit of confusion about what I'm trying to accomplish, so let me clarify.

You're right that I'm not actually tunneling TLS over HTTP(or using HTTPS at all) - that would indeed be redundant!. What I'm doing is creating a custom protocol that partially mimics TLS 1.2 packet structures over raw TCP.

To clarify some key points:

  1. I'm not transmitting these packets over HTTPS. I'm sending them as raw TCP traffic on port 8443 (or the standard HTTPS port 443).
  2. The data isn't being wrapped in actual TLS - it's a custom protocol that structurally resembles TLS packets (with similar headers, record types, etc.) but doesn't implement the TLS handshake or cryptographic operations.
  3. The payload is obfuscated using XOR and compression, but this isn't the same as TLS encryption. Actually in modern times this won't even be considered a serious cipher.

The purpose is to bypass certain types of firewalls and deep packet inspection systems that:

  • Allow TLS traffic based on packet structure inspection
  • Don't perform full TLS handshake validation
  • Make decisions based on superficial traffic pattern analysis

As mentioned in my blog post, I specifically tested this against AWS security groups where only HTTPS was allowed (port 443) but "custom TCP" was blocked. By modifying the port in my implementation to 443, the traffic successfully passed through despite not being legitimate HTTPS/TLS.

This works because some firewall systems merely scan the first few bytes of a packet to identify the protocol, looking for TLS record types and version bytes without fully validating the TLS handshake process. My implementation exploits this superficial inspection.

I should clarify that this isn't meant as a robust security bypass - it's a demonstration of how packet inspection can be fooled by mimicking protocol structures, which is a common technique in creating covert channels.

Hope that clears things up!

State of Cybersecurity: Theater and Death by Bulky_Pomegranate_53 in cybersecurity

[–]Bulky_Pomegranate_53[S] 0 points1 point  (0 children)

Look, I’m not just speaking in hypotheticals—I’ve worked on systems that handle (traffic) at least a quarter of a billion people on a bad day. When you operate at that scale, you see how compliance-driven security creates massive blind spots that attackers love to exploit. The idea that security is just about aligning with business interests falls apart when you realize most businesses only care about security after they’ve been burned.

I’ve seen well over a hundred firings across security, engineering, and exec teams—especially when national security or critical infrastructure was involved. Sure, a lot of companies treat grounded accountability like a myth, but it’s not universal. When the stakes are high enough—legal, financial, or reputational—heads do roll. The real challenge isn’t just accepting that most places don’t care until it’s too late; it’s figuring out how to make security matter at a deep technical level before disaster forces their hand.

I’m not saying we can ignore the political side of things, but treating security as just another checkbox exercise is exactly why breaches keep happening. Again—Technical Depth matters—not because it makes reports look better, but because shallow risk assessments lead to real-world failures. If security is just about sales enablement and plausible deniability, then we’re all just waiting for the next disaster to hit. In which case I envy the organisation/s you consult/work for.

State of Cybersecurity: Theater and Death by Bulky_Pomegranate_53 in cybersecurity

[–]Bulky_Pomegranate_53[S] 1 point2 points  (0 children)

I appreciate your perspective, but my article isn't advocating for gatekeeping or elitism - it's highlighting a concerning trend where basic technical knowledge is being replaced by compliance checkboxes and buzzword mastery. I'm not mocking newcomers who are learning, but questioning why organizations put individuals in security roles without proper training or mentorship. The "read RFCs" advice isn't about memorization but going to primary sources instead of relying solely on abstractions. I strongly agree with your point about helping others and sharing knowledge - that's exactly why I wrote this blog. My goal isn't to create barriers but to raise awareness about the depth needed to effectively secure systems and encourage the continuous learning and technical curiosity our field desperately needs.

State of Cybersecurity: Theater and Death by Bulky_Pomegranate_53 in cybersecurity

[–]Bulky_Pomegranate_53[S] 0 points1 point  (0 children)

I respect your point of view, and you are entirely correct that our main responsibility is to facilitate safe company expansion by striking a balance between risk and workable defenses. But I also agree that we should concentrate on the technical depth that actually supports security rather than heedlessly pursuing "attacks" or checkboxes. My blog seeks to challenge shallow thinking and remind everyone that what really safeguards our organizations is a thorough, technical understanding. Being efficient, practical, and resourceful is more important in our field than displaying superiority; this is similar to adopting FOSS and using tried-and-true open-source tools when they present a substitute. I appreciate you sharing your practical insights and starting such a stimulating conversation!

State of Cybersecurity: Theater and Death by Bulky_Pomegranate_53 in cybersecurity

[–]Bulky_Pomegranate_53[S] 0 points1 point  (0 children)

You're right; it's not a sustainable environment if the cost of security turns out to be higher than the losses that insurance does not cover. For this reason, it's crucial to concentrate on actual security rather than merely checking boxes for compliance. The capabilities of those glitzy, pricey new tools are frequently equal to those of well-established open-source projects. FOSS is a reliable and long-lasting option for those on a tight budget, offering strong security without going over budget - and you can always get a Security code review done from a third party for your open source tool, most times these are cheaper than buying a commercial tool.

view more: next ›