Hyperscale Security

As a profession, cyber/information security has been telling itself that it is “risk-based”, but often fails to live up to that in practice. We see this from hyping threats because they're cool and make for a good conference talk, to having to make a market for a new Gartner product category.

We therefore often mistake the possible for the probable, and the PoC for a Production threat we have to invest to fix. Nowhere is this more extreme than in post quantum cryptography (PQC) and the false urgency of fixing it now, just in case.

Crypto Agility and PQC

Don't get me wrong. Crypto agility and PQC are good things. It is good to know which libraries in your code provide crypto functions so you can keep them up-to-date, whether for PQC or otherwise. That is not the debate. What I have trouble with is the urgency on a problem that everybody agrees to isn't real yet. There are no working quantum computers. Estimates are 5 (optimistic) to 10 (more realistic) to 20 (maybe) years out. Are we still doing risk-based infosec if we're spending time and effort on a problem that realistically won't occur for years?

Are we, when most organizations can't even keep on top of known vulnerabilities or running an effective CSPM program? Between your phishing defense, ransomware resilience and XDR adoption, where does this rate?

“Harvest Now, Decrypt Later” isn't Real

“Oh, but adversaries could capture TLS traffic, store it till a later date and decrypt when quantum computers are viable”.

Yes. Theoretically. But TLS + storage for 10 years is not free – especially when you consider the volume of TLS traffic that runs across the internet on a continuous basis. Google Search gives me daily internet traffic volumes running from 33 exabytes to 0.4 zettabytes which is quite the range, but enough to make it clear that is “stupid scale”. Therefore, simply due to volume, any HNDL would have to be targeted. Unless you're a foreign government or critical industry, that almost certainly already puts you outside of danger.

But BGP Hijacks...

BGP hijacks do happen, where adversaries route vast traffic volumes through infrastructure they control. This is almost certainly to capture metadata, not to HNDL. Even after filtering, what worth is a snapshot of a few hours or days after a decade? At the very least you'd want a continuous stream.

BGP hijacks would be incredibly wasteful to adversaries – storing data in the hope a fragment of a conversation might one day prove useful.

What About Targeted Organizations or Journalists?

If you're a targeted organization watch your XDR and network detection! If you're a journalist, use safe modes and reboot often as surveillance tools targeting you are already on the market.

You're WRONG, I have Clearance and Know it Happens

Very good. And maybe it is, but that still doesn't mean it's a threat. Those adversaries may believe it and waste their time. And you should still start your crypto agility program if not already done, for reasons nothing to do with PQC. Either way, I am happy to admit I am wrong, if that proves to be the case a decade from now. I'll wear the badge “PQC, The One I Got Wrong”.

But I'll take those chances. At least as long as the front doors remain wide open in most of our organizations.

cloud security posts without corporate approval @jaythvv@infosec.exchange

The agreements on data sharing between the EU and the US have been problematic from the start, due to irreconcilable difference in privacy principles. From Safe Harbor to Privacy Shield(s), each time it was clear that any agreement would be challenged. In the meantime, the world moved on regardless.

The debate flares up now, again, because of the fast-changing relationship between the US and Europe, following the first months of a chaotic Trump presidency that is re-defining global alliances. But a lot of the discussion is emotional and imprecise. I am as concerned about security and privacy for private citizens as the next one. But that shouldn't jump to wild claims that the US government can just get at anyone's data or cut them off.

Not All Cloud is the Same

When we're talking about American cloud services, are we talking Google Search and Gmail , Office 365, Facebook, WhatsApp, or Twitter/X? Or are we talking about cloud infrastructure and services like AWS, Azure, Google Cloud? In the first, you don't pay, have no control, and trade your privacy for convenience. In the latter, you orchestrate all your compute, network and storage services, and have access to encryption services of varying strengths. Services like AWS Nitro are specifically designed to guarantee AWS administrators can't access their customers' workloads, and Sovereign Cloud offerings take this further and further.

The debate of privacy of citizens – that is, move to Signal or Fediverse services – is not the same as the debate of European corporate and governmental use of American cloud infrastructure providers. The arguments against Google's and Meta's dominance in retail internet service and advertisement are not new, or suddenly more problematic with the change in US Administrations. Similarly, cloud infrastructure services are not suddenly at greater risk.

Residence or Remote Control?

We talk about EU-only access and data residency, but we forget what is really important about that. If Microsoft can access a server in Europe from America, what use is EU data residency? With strong encryption, the physical location of data on disk doesn't really matter. If the American provider doesn't have access to the key, the European data owner still controls the data.

Meanwhile, the physical equipment and data centers are still in Europe, operated be local residents and subject to local jurisdictions. When Russian sanctions came in, many global technology companies retreated under realistic threat of their facilities being nationalized or “sold” to a local operator. That is an extreme example, but EU governments are not powerless.

The moment the legal status of American cloud infrastructure providers becomes a real problem, immediately you see the foundation of AWS, Europe, Azure Europe and Google Cloud Europe as independent, European corporations.

Can Open Source Save Europe?

Maybe. But not on its own. The top 7 (or 6, if you count Github as Microsoft) corporate contributors are American tech corporations until you get to SAP, and open source software is used equally on both sides of the Atlantic for cloud services.

Does the open source have to be European for independence? Who cares where it comes from? Fork open source projects you rely on, if necessary. Cloud services based on open source are not inherently more secure, private and independent. They still need to be operated by someone. And often the American cloud providers rent from local data center operators.

Lack of Capital, Fragmented Market

The problem of Europe and cloud independence is the lack of capital. While there are 4-5 American global cloud infrastructure providers, there isn't a single one that can claim that from Europe. The market is fragmented with national and regional providers.

Initiatives like IPCEI CIS are interesting, but would still create an odd cloud where services would be provided by a wide variety of different supplier, greater complexity, and lower economies of scale. It's a noble pursuit, but a political one.

Technological Interdependence

We focus on European dependence on America... but we fail to do the same in reverse. There is more competition in cloud infrastructure and services than there is in semiconductor design (Arm Holdings, UK) and photolithography (ASML, NL) or the business application software that runs the global economy and government services (SAP, D).

Serious Times

That is not to say there isn't a problem. We live in strange times, and will have to rethink our threat models. But for the debate to be productive, we need to be nuanced what the real problems are. And not let ourselves be ruled by broad strokes and emotions.

cloud security posts without corporate approval @jaythvv@infosec.exchange

Earlier this week, someone asked me for my top 5-10 things I would recommend to an organization lifting & shifting workloads to public cloud. I thought that was a good starting point. “Refactor” for cloud-native is the common answer, but the reality is that everybody lifts & shifts, so why not recognize that.

So, here are my top 5... and I'll add a sixth as a bonus.

1. Centralize and automate cloud account creation and billing, and ensure that all are in your public cloud Organization. This will allow you to apply policies centrally, and more easily deploy cloud-native security tooling.

2. Apply cloud guardrails at that Organization level to apply basic preventative controls and make your cloud accounts behave more secure-by-default. These are likely the cheapest and most effective security controls you can apply to enforce logging, encryption standards, network restrictions, MFA enforcement, etc.

3. Get a Cloud-Native Application Protection Platform (CNAPP). This can be deployed via Organization policy and provides broad visibility to your cloud estate, across providers and for multiple use cases, including asset discovery, CSPM and vulnerability management.

4. Related to that, while lifting & shifting your workloads, resist the urge to lift & shift your secure tooling from the data center. Look at what the CNAPP gives you, and see whether you may not be able to rationalize your security stack, retire point solutions you no longer need, and reduce cost.

5. Cloud APIs give you the opportunity to describe the infrastructure and services you want and have the cloud materialize that for you, rather than do everything yourself. It is designed for automation. Use Infrastructure-as-Code (IaC) to create your infrastructure, network and service configuration, create compute instances and deploy your VM images. IaC allows you to redeploy from known-good state, which accelerates patching, system configuration and restoration, while making deployments more predictable.

The Cloud is Metered

One bonus recommendation, given the difference between owned and rented compute, network and storage resources. Remember that everything in the cloud is metered and that your architectural choices have potential significant cost impacts. Don't size like in data centers with head room to spare. Figure out what your workload needs. Smaller instances but many of them may be cheaper than fewer large instances. If the workload is variable (seasonal, variable during the day), consider autoscaling. If the workload is static, use reserved instances at lower cost.

And after you have done all that, feel free to refactor!

cloud security posts without corporate approval @jaythvv@infosec.exchange

I spent last week at Headquarters which is always great to talk directly with many security colleagues in a short amount of time – and not just in the office, but also dinner and drinks. That always allows for conversations that can go deeper and more passionate – and sometimes more honest – than you get in the day time, let alone when meeting virtually. Especially when you've known each other for years.

Thursday was the local Cybersecurity Awareness Month event, and I was invited for an Executive Q&A on our security strategy and direction. To continue the conversation, I invited those interested to dinner after to close out my week before flying back home. This is how I found myself opposite my oldest friend in the security organization, deeply engaged on one of his favorite topics: open source security.

“But That Stuff is Boring!”

He wanted to talk about protecting against zero days in the most common open source components used in our solutions. Admirable, but aside from the greater risks from known vulnerabilities, how would you do that? Not knowing they exist, such zero days by definition would have slipped through our SAST and DAST scanning. So, are you proposing we run continuous fuzzing tests against such components and dependent libraries, in addition?

We can engage the internal security community (another one of his favorite topics), he replied. They can submit vulnerabilities and pull requests to the maintainers. And we could patch our landscape even before the vulnerability is disclosed.

Wait, you're suggesting we fork the library and deploy a patch, rather than wait for the fix to be released by the maintainers? And then how do we get back on the official version? Do we force all the developer teams to patch twice for a zero day nobody knows about and we have no evidence is exploited in the wild? Why wouldn't we just manage it through the existing known vulnerability management processes with established SLAs, and if necessary deploy a temporary detection or mitigation?

Oh, but that stuff is boring...

Ignoring the Boring Makes Us Vulnerable

We have such a habit in infosec to chase after the esoteric and interesting. It is encouraged through conferences and social media fame. The cybersecurity industry adds to it, whether for marketing reasons or added features without guidance or consideration how to operationalize them but demo well. We like intellectually interesting problems we can solve on our own. But then we shouldn't be surprised when the basics aren't taken care of, and developer teams consider us burdensome and adding irrelevant toil.

I get that it may not be as much fun to chase after teams with reports on alerts or missing evidence for compliance controls, help teams to manage a never ending stream of newly reported vulnerabilities against SLAs, or to improve asset discovery and metadata management, rather than chase after zero days. But the boring basics are what truly reduces the attack surface. Ignoring the boring is what continues to make us vulnerable.

Finding Excitement in the Boring

To solve the big problems in security, we must find excitement in the boring. Let's focus our minds on how we implement and operationalize least-privilege IAM and secrets, how we can make CI/CD pipelines both more secure and efficient for developer teams to allow for greater code quality and higher velocity, and provide secure-by-default infrastructure, platforms and services that enable teams to be more productive without getting in their way. Find the intellectual challenge in security engineering and operations. We must work on the risks we face, not the threats we like.

cloud security posts without corporate approval @jaythvv@infosec.exchange

Security is a tough discipline. To do it well requires focus, so we don't spin our wheels, spend effort and budget, or get distracted by the latest hype. It is unfortunate, therefore, that we often get caught in dogmas we tell ourselves, but we don't examine whether they are correct or even useful. Here are three such dogmas that are just plain wrong.

1. Defenders Have to be Right All the Time, Attackers Only Once

If this was ever true, it certainly isn't today. A quick look at the MITRE ATT&CK framework makes it very clear that there are many stages in attacks, from reconnaissance to initial access to execution and persistence, just to gain a first foothold in a defender's landscape. Before a threat actor gets to actual data collection and exfiltration, or a ransomware attack, he or she needs to get a lot of things right – all of which could potentially be detected.

A layered defense that presents multiple obstacles also means that the defender may not get it right all the time – a vulnerability in a container, a misconfiguration in the network architecture, an open RDP port – but should still have multiple opportunities to detect malicious activity before the attacker is at your crown jewels. Lateral movement, privilege escalation, creation of rogue resources or user accounts all give opportunities to detect an attack in progress, and as long as an attacker has no access to a KMS may never get to encrypted data or into databases.

The dogma doesn't recognize the advantages of defenders and ignores the obstacles attackers must overcome. Attackers need to be right all the time. Defenders have multiple opportunities to stop them.

2. No Security Through Obscurity

This is often repeated, but as a result prevents us from taking the benefits of obscurity as part of a layered defense. Run an SSH open to the public internet on port 22 and it will be hammered constantly by automated scripts. Run it on a high random port and it will see virtually no traffic. Only very persistent threat actors focused on a particular target victim will scan for all open ports.

And if defenders were diligent enough to run SSH on a high randomly chosen port, logs showing failed logins will present a far more valuable and reliable alert than the noise that comes with SSH on port 22.

3. Zero Trust Network Architecture

This is possibly the most controversial dogma at all, as it seems the entire industry has lost their mind over this. NIST SP 800-207, the relevant Zero Trust standard says:

Zero trust focuses on protecting resources (assets, services, workflows, network accounts, etc.), not network segments, as the network location is no longer seen as the prime component to the security posture of the resource

So, it correctly starts with the premise that the network cannot be trusted... and yet spends most of the document discussion network controls, trying to re-establish trust in the network.

Trying to fix IAM, application context, and network security all at the same time, by adding a new policy control overlay in the network to implement the user access controls we should already have on application level. But why? Didn't we just declare the network no longer trusted? Especially in a cloud landscape, you may even end up creating network connections that don't need to exist. Why prevent a user access to a resource by network they already don't have access to on application level? The problem is IAM and that is hard enough. We can manage IAM and application context with Workload Identities for service accounts. Why complicate it further by adding the network back in?

Organizations struggle already with the basics. Why set them up for failure with a massive ZTNA implementation? IAM is boring and network security companies have products to sell?

Abandon the Idea that it's Not Good Enough Unless it's Perfect

There is this joke that goes that the only secure computer is one that is locked away in a separate room, does not have mouse, keyboard or screen, has no network connection, and is powered off. This is supposed to be instructive to get the balance of confidentiality and integrity right in relation to availability. It's intended to show that perfect security is not possible. It is not to be taken seriously as reasonable security guidance.

We supposedly moved at least a decade ago to a risk-based approach. However it seems a good portion of our industry continues to look for the perfect, and anything less is not good enough. Is it any surprise that there is such a gulf between security consultants, advisors and policy writers on the one hand and practitioners on the other? Let's abandon our perfect dogmas so we can focus on the actually important security operational problems.

cloud security posts without corporate approval @jaythvv@infosec.exchange

Any week in the security press proves that, generally, most companies and institutions have struggled to implement adequate or even basic security protections, despite best intentions and effort. While the move to the cloud has its own risks, whether for IaaS, PaaS and SaaS, it also provides the opportunity to outsource many security responsibilities to a cloud provider. The cloud platforms have many security and resiliency features baked in, and it can be reasonably argued that cloud providers can bring more resources and talent to bear and through economies of scale can do a better job than their customers can.

Aside from agility and flexibility of cloud solutions, for each organization individually, a move to the cloud can be a real security and resiliency net-benefit, compared to running critical systems themselves.

Decentralized Inadequacy vs Centralized Competence

To take just one example. Organizations notoriously struggle with keeping systems up-to-date, with new vulnerabilities being disclosed all the time. Rather than having to manage that yourself, using an always-at-the-latest-version SaaS solution is a real security benefit. For each organization separately, but also in aggregate.

We have to recognize, though, that there are not that many cloud providers that we all rely on. The companies listed in the Cloud Wars Top 10 – and full disclosure, I work for one – increasingly run the critical workloads that we all rely on as customers, employees and citizens. That means if anything goes significantly wrong the impact may be widespread.

We are moving from a situation where the likelihood of an individual failure in confidentiality, integrity or availability (CIA) is higher but the impact is contained, to one where the likelihood is lower, but the impact could be catastrophic.

The Colonial Pipeline Ransomware Attack led to the shutdown of all pipeline operations by the company and caused widespread fuel shortages across the US East Coast. What is often forgotten is that the ransomware affected the billing infrastructure, not the operational systems. With such administrative systems increasingly moving to the cloud, a major incident at a cloud provider affecting thousands of companies all at the same time would have devastating cascading effects throughout the global economy and the functioning of society.

Cloud as Critical Infrastructure

I think it is reasonable therefore to see cloud providers as critical infrastructure. The IT Sector in general already is designated as such, but these designations don't yet specifically focus on the unique and growing role of cloud providers within that sector as the providers of services to everybody else.

Cloud security has so far mostly focused on the consumer-side of the Shared Responsibility model in-the-cloud. Cloud providers have also started to recognize they have a responsibility to help their custoemrs run more securely. More recently, security issues of-the-cloud such as recorded in the Cloud Vulnerability Database have got more attention, showing that the cloud providers aren't perfect. A recent incident prompted a US Senator to criticize one of them for “negligent cybersecurity practices”.

It is time that cloud providers are held to a greater level of scrutiny on their own internal operations. If failure can have significant impact on the economy, the functioning of society, and even lives, we should expect similar oversight and consequences as in Utilities, Finance or Healthcare.

cloud security posts without corporate approval @jaythvv@infosec.exchange

It just about two weeks before RSA Conference 2023, and the hype train accelerates even beyond its usual fever pitch. Learn what the latest threats are you should definitely buy a new tool for. Find out what version of Zero Trust we're at and what generation the latest NextGen Firewall. See which cybersecurity startup has the biggest booth.

Blockchain! Zero Trust! Ransomware! Software Supply Chain! DSPM! ChatGPT!

Is XDR still hip? In cloud security, nobody even wants to say “CSPM” anymore, and CNAPP's oxygen is increasingly stolen by DSPM, the newest kid on the block. It could have been CIEM, but that is such a poorly named category that it didn't make it. CIEM probably is an IAM subcategory anyway, but that sounds so old-fashioned, boring and unsexy.

But none of that matters, anyway, because since ChatGPT was released, the entire cybersecurity industry has an opinion on the dangers and risks, as well as possible benefits of Large Language Models.

“ChatGPT-enabled” will be all over the show floor.

It's the Basics, Stupid!

Reports by the vendors of our shiny tools, such as this recent one by Qualys, show that we may have shiny tools, but they just record poor security postures. Visibility is better than having nothing at all, but deployment of tooling is just the beginning. Next comes the engineering of contextualizing alerts and findings, enrichment with metadata, and the ability to attribute them to the right team in the organization that can do something about them. Then comes the reporting, SLA tracking and organizational accountability, the developer and workforce enablement and security awareness, and compliance processes.

Everybody wants to evaluate tools, run PoCs, define security architecture, requirements and policies for others to follow. But we shy away from doing the hard work of making our environments more secure. That, we say, is someone else's problem. If only the developers and ops people would just do what we say...

It is still about the “basics” – the unsexy, really hard things you need to do:

• Asset Inventory Management
• IAM and Access Control
• Network Controls
• Encryption in-transit and at-rest
• Keys and Secrets Management
• Logging and Monitoring
• Compliance and Vulnerability Management

Zero Trust requires that you do all these things to be effective. The same is true for ransomware or data extortion attacks. We debate esoteric, academic risks and conceptual frameworks instead of how to practically run effective security programs. We talk about post-quantum cryptography when NIST hasn't established standards yet, and we still can't get our organizations to rotate keys periodically.

The Real Innovation is in Sec(Dev)Ops

I have been in Silicon Valley over 20 years. When all the hype was about the gig economy, social media and the startups in the city, the real innovation took place in the Valley (and Seattle/Bellevue, to be fair) – where big tech companies were figuring out how to run large data center and cloud services.

I have the feeling we're going through the same thing in cybersecurity at the moment. The industry is off doing their own thing that gets a lot of attention and is unquestionably overfunded, while SecOps teams within organizations are adopting cloud-native and DevOps practices to innovate and engineer new processes to drive effective security outcomes. Often based on open source solutions.

That is not sustainable. Budgets are flat or tightening. And the industry can't reprice itself because it is too leveraged.

Have a fun RSA, everyone. It may be the last exuberant one before the crash.

cloud security posts without corporate approval @jaythvv@infosec.exchange

A colleague of mine I worked with extensively over the past months told me that she attended a security conference this week, but left early. I asked why.

There was nothing there that was relevant to me.

This was not a new experience to me and I congratulated her that she passed a significant milestone. When you focus on cloud security, this is not unusual. The last few years I have found that the most relevant conferences were DevOps and cloud-native conferences, where security was only an aspect – be it an important one – of the conference scope or cloud security-specific gatherings, rather than the more typical cybersecurity conferences, where cloud is often absent. This goes for the big name conferences as well as smaller events.

Stuck in What We Know

I recently spoke at a two-day closed audience cybersecurity conference. It was filled with fascinating talks, but the only cloud security session was mine. This low representation is not unique to smaller events, but also the case for the big-name conferences like RSA, Defcon and Blackhat, CCC conferences, and others.

Malware, ransomware, phishing, appsec, data privacy, memory corruptions, data privacy, OSS-, software supply chain- and network security are all important topics, and conferences want to cater to a broad audience. But infosec/cybersecurity conferences seem to be stuck in familiar territory while around us the world is in the middle of a massive cloud transformation.

Cloud Security is Elsewhere

I yearly get my talk proposals rejected by the RSA selection committee – it's OK, the feeling is mutual ;) – but colleagues of mine and myself have presented repeatedly on cloud security at fwd:cloudsec, KubeCon, ChefConf, and elsewhere. The first is a cloud security specific conference, the other two are cloud-native and DevOps conferences where security is not the only topic.

Cloud security seems to be largely debated via blogs, podcasts and social media, and aside from a few exceptions, a “guest” at others' events. It reminds me a bit of drum & bass in dance music, largely happening via (initially) pirate radio, the internet, a small side room at multi-stage party, and the occasional club with a DnB-only night on a Monday or Tuesday.

Developer Autonomy and the Irrelevance of a Department of No

In a cloud landscape, the traditional gatekeepers are gone. Rather than network security teams or infrastructure provisioning teams providing some level of central control, developer teams through everything-as-code deploy entire landscapes independently from such gatekeepers, and have far greater autonomy. They may choose cloud-native platforms that your traditional security tooling doesn't know what to do with. Modern CI/CD pipelines with frequent deployments require security teams to respond far more quickly than they are used to, and pose whole new challenges they haven't seen before.

A Department of No that is not prepared for the threats and risks of the cloud as the organization around them rushes into cloud transformation is at risk to become irrelevant and likely to be ignored.

Cloud Security Must Have a Place in the Mainstream

Security teams are often slow to respond to our employers racing into the cloud . That goes for security standards as well, with ISO and NIST only slowly becoming aware of the cloud. Security certifications lag as well. Since cloud security is underrepresented in the usual cybersecurity information channels, it is not easily accessible.

Cloud providers and cloud security vendors have done good work, but how does someone new to the topic navigate this ever evolving market and know who to trust? Even if you select good vendors, how do you operationalize their solutions into your processes? Where do you learn from prior experience?

How would you know that the best cloud security practitioners network is on LinkedIn? How would you get to know the key contributors to follow to grow your network, and get into the stream of blogs, podcasts and events where cloud security approaches and practices are shared, based on actual experience? Even that is only, as far as I know.

It is high time that cloud security finds a place in the infosec mainstream, to establish more structured and stable fora to share practices broadly – to those coming into the cloud security community new – and deeply – for those already there.

cloud security posts without corporate approval @jaythvv@infosec.exchange

However varied our journeys into security are, we tend to come from two very different but specific backgrounds. One segment consider themselves hackers. The other originates in “milfed”, that is, the military, signal intelligence and law enforcement.

We are two tribes, distinctive enough that we each even call our industry by different names. To Hackers it is infosec. To Feds it is cybersecurity.

Hackers

Hackers are those that messed about with computers at home or university, meeting up with others online or a hackerspace if one happened to be nearby. This is the world of phreakers and explorers, cypherpunks, IRC and phrack.org, which published seminal papers such as Smashing the Stack for Fun and Profit and The Hacker Manifesto. In this group you find high levels of support for Wikileaks and Snowden (at least initially), and Anonymous, Occupy, or BLM, if not active participation. Unsurprisingly, this tribe trends anti-authoritarian, even anarchist/libertarian.

This group dominates in Europe, and specifically, on the European continent. Germany especially, with its Chaos Computer Club, combines the hacker ethic with a social consciousness, focusing strongly on the effect of technology on society, and actively pursuing campaigns towards privacy protection of security of citizens. The L0pht notwithstanding, security seemed less of a topic in American hacker culture to me, as a European who moved to Silicon Valley. The Homebrew Computer Club, for instance, always struck me more as makers rather than breakers. Either way, this tribe has a natural playfulness.

Feds

Feds include those with a military, intelligence or law enforcement background. This group dominates in the US, other “Five Eyes” countries and Israel, coming from agencies such as NSA, GCHQ or Unit 8200, etc. but also the FBI or other police forces.

Culturally, with ranks and orders, this means a more hierarchical, authoritarian outlook, and its members are used to operate in far more structured environments. This is a much more serious tribe, coming up within a context of fighting crime or conflicts. This group believes in rules, policies and procedures, and expects them to be followed.

Natural Enemies

I remember the outrage in the hacker community when General Keith Alexander, at the time head of the NSA and US Cyber Command gave the keynote at Defcon 20. Known already for being attended by a variety of Feds leading to its nickname “Fedcon”, many (at least for a while) turned their back on the conference.

The Feds were the enemy. They went after Hackers that weren't cybercriminals – at least in the eyes of the Hackers. They were the ones that turned Sabu. They were the ones that started the Crypto Wars and pushed NIST to include a flawed algorithm in their encryption standard.

And Then We Had Bills to Pay...

As Hackers got older and Feds left the service, we got married and got mortgages. We found ourselves thrown together in the companies and organizations building up security teams and functions, or developing security tooling, protecting systems against ever more professional and sophisticated attackers. We became colleagues, partners, vendors and buyers, and had to work together, whether we liked to or not.

But it has largely worked out. More even than paying the bills, I am convinced that our shared deep concern for security and privacy allowed us to look beyond our differences and build relationships. Still unquestionably a Hacker, I work closely with and for Feds, with great shared mutual respect. They have been and are mentors just as dear as Aleph One.

In hindsight, now about 10 years later, General Alexander's keynote sounds like a brave – if sometimes awkward – invitation to a justifiably reluctant audience. It also sounds far less controversial and even prescient, stressing a “shared responsibility” and working together with industry and the hacker community that is now manifested through CISA and still echoes through the White House's National Cybersecurity Strategy published this week.

If Hackers and Feds Can Do It

What is so fascinating is how we manage to work together and trust each other without losing our respective identities. I am still a Hacker, I don't feel I have “sold out” or anything. My Fed colleagues and partners haven't suddenly become Hackers, either. The Venn diagram of Hackers and Feds remains pretty much two circles. With shared goals to protect society against cyber threats, these unlikely partners rise above our differences to drive meaningful security programs, though.

That gives me hope for society as a whole, and our ability to build bridges across different tribes, cultures, subcultures and other divisions. If Hackers and Feds can do it...

cloud security posts without corporate approval @jaythvv@infosec.exchange

This blog started as a Mastodon exchange with Program J and Michael Olsen. They are not responsible for me stretching the metaphor to breaking point. Any similarity to real secret society ranks and titles is only meant to be illustrative.

Barriers to Entry

We have supposedly 3-4 million open cybersecurity position globally, and 700,000 alone in the US, yet it remains notoriously difficult for interested aspirants to break into the industry. Job requirements set unrealistic expectations, while candidates are expected to get a variety of certifications from organizations the industry doesn't even necessarily trust, and may still not get you a job because you lack experience.

Meanwhile those already in the industry, especially those in leadership positions and decades of experience, often got in by accident, through proven skill, or knowing the right people. Their own career trajectories are so often unusual to the point that it warranted its own podcast series on ITSP Magazine, The Uncommon Journey podcast series at some point.

Despite excellent work done by people and organizations helping those looking to break in, we seem to have a structural problem where we set unrealistic barriers we never applied to ourselves. That makes infosec less a mature profession than a modern-day secret society, a 21st century masonic lodge.

Entry through Introduction

Entry into secret societies is through introduction by an existing adept, vouching for the prospective initiate. Once you manage that first introduction and your first job, you've completed your initiation and are part of the group.

Regardless of your certs, the more senior the adept making the introduction, the higher the initiate's entry level. Tough luck if you don't know any, though.

Secret Codes and Symbols

The profession is filled with multi-layered secret knowledge and jargon, with lower levels of esoterica filled with alphabet soup acronyms invented by analysts, only to discover at higher levels of initiation that those are a smoke screen to distract you from the truth that DLP and DSPM are just aspects of data security; NGFW, WAF, IDS/IPS and NDR are network security; and Zero Trust, CIEM and IAM are identity, authentication, authorization and role-based access control.

Our rituals are conference talks, where we talk in jargon about esoteric topics showing terminal windows and code fragments, demonstrating exploits perhaps only some understand, filled with memes, troll faces and cat pictures to throw off the uninitiated. We perform ritual libations for first-time speakers. We post memorials on the blockchain.

Public knowledge is published in standards, but even then we might put them behind a paywall or require a membership. It comes from the cybersecurity vendors to sow fear, uncertainty and doubt. Increasingly secret and deeper knowledge is exchanged in podcasts, LinkedIn posts, blogs, social media (where we may switch platforms if we so wish without telling anyone), github commits or closed chat channels.

Some Masters are frauds, some turn out to be utter abusive assholes. Only insiders know who they are.

Tribes and Clans

We have tribal categories of Hackers and Feds, and separate ones of Red, Blue, and Purple teams with the first determining your Ancestry and the second your Guild – and that doesn't even include the Wizard tribe of cybercriminals who you don't meet until they join one of the main tribes, you gain their trust or they get arrested.

Seniority among the Hacker tribe is determined by how many Defcons you attended or villages you hosted, how many even more obscure Chaos Computer Club conferences you attended, or through legendary exploits. Seniority among the Feds is counted in years of service and what level of classification you're cleared for.

The tribes are broken down into clans whose characteristics you only learn through further levels of initiation.

The Policy clan of academics are idealists, whereas the Industry Analyst clan claim broad knowledge without worrying too much about the nature of True Reality. The SOC and SecOps clans, meanwhile, accept those with book knowledge are well-intentioned but insist they don't know what they're talking about.

Cloudsec and DevSecOps clans want to change all the others' mindset and update all the rituals, saying the old magic doesn't work anymore.

The Signal Intelligence (NSA, GCHQ, BND, etc.) clan doesn't talk, can't talk about anything, but lends credibility to your meeting with other tribesmen.

The Accountants of GRC and Audit, the State Regulatory Church, the serial startup founders and the corporate behemoths of the cybersecurity industry, the data privacy clan that isn't even sure if they're still in the same secret society anymore...

Can we talk about the Furries?

Ceremonial Robes

Security Researcher, Pentester and Red Team clans can wear pretty outrageous attire and facial jewelry. The SOC and SecOps wears dark and muted clothes. Cloud sec dyes their hair in all colors. They all wear hoodies.

The GRC clan, of course, wears collared shirts and shaves. Signal Intelligence khakis and blue blazers.

The Furries... well...

Not The Sign of a Mature Industry

However fun this all may be, this is not the sign of a mature industry or profession. It neither helps us bring in new talent, nor does it help us communicating to the business and the board room. However comfortable it may be, it has become self-destructive. It's time to throw open the doors and go mainstream.

Secret societies aren't bad. Masonic lodges promoted Enlightenment ideals when that was still radical, and allowed people to exchange ideas while transcending social classes. When society as a whole moves on, though, and hackers getting together no longer risk arrest but represent a 200 billion industry, protect trillions of economic activity and our integrity as humans and citizens, it is time to grow up.

cloud security posts without corporate approval @jaythvv@infosec.exchange