Hyperscale Security

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

So, just to be clear – I am writing this in a liminal mindset of mild alcoholic intoxication, but frankly, that should be quite appropriate to the topic, being a rather liminal space of its own.

One of the things I am particularly fond of are liminal spaces. These are:

Liminal space refers to the place a person is in during a transitional period. It’s a gap, and can be physical (like a doorway), emotional (like a divorce) or metaphorical (like a decision).

“This is where one thing ends and another is about to begin, but you are not quite there yet, you are in the space between,” says New York-based mindset expert Kirsten Franklin, a transformation coach who works regularly with professional athletes and high-level executives.

The tricky part to negotiating this void is that it also holds a huge helping of the unknown. And by and large, experts say, humans don’t like to exist in a space of unpredictability.

source: Liminal Space: What Is It And How Does It Affect Your Mental Health?

See, I disagree with this idea of not liking to exist in a space of unpredictability. I am actually very comfortable with that and such in-between spaces. I revel in them and appreciate their special character and opportunity.

What I feel is a missing from the definition is a temporal aspect. It is not just an in-between space. It's an in-between time space as well. Airports, but even more the actual flights themselves, are perfect examples of that. We're thrown together with a bunch of people in transit, cut off from the rest of the world for a period of time. International flights, lasting 10+ hours, are complete out-of-time experiences, disorienting us from the local time at our destinations.

I love hotel bars. Hotel bars, compared to air travel, are more spatially settled and located, but are just as transitory as airplanes, where normal time is suspended. They are filled with jetlagged guests. And they provide far more opportunities for interaction and adventure.

Ships Passing in the Night

Business travel, whether US domestic or international, involves different in time zones, adding to a general liminal sense. The hotel bar is a 21st century port, where people from different time and spatial dimensions congregate. We're all from somewhere else, and even locals invited as guests of visitors tend to feel a little out of place. After all, if you're local, why are you here? Who or what are you here for?

Magic happens in hotel bars.

We're from every place and every hour.

We speak different languages, grew up different places.

We're every age and every gender.

We're away from home and will never see each other again.

Unusual trust and connection occurs between strangers.

Emotional, spiritual, ... physical.

Liminal Relationships

I remember a Mongolian in Beijing. An Australian colleague in Tokyo. A southerner in New York. A Mexican in Dallas. Gringos terrified in Mexico. A Texan in Frankfurt. Colleagues from Shanghai. Others from Singapore. A South-African in Germany. Mainland Chinese in Melbourne. Italians in Buenos Aires. A Fijian in Atlanta. Iranians in China.

Lost in Translation

Lost in Translation, the movie directed by Sofia Coppola and starring Scarlett Johansson and Bill Murray is the ultimate liminal space and time movie. Much of the movie is spent in jetlagged and liminal confusion wherein the hotel bar plays a strange anchoring role of stability. It's where we go when we feel alone and restless and cannot sleep. It provides a safe port in a strange land where we don't know the rules and local dynamics. It's where we're connecting across time and space. It's where we bond, make plans, and hook up. It's where we're protected by security guards and glass doors from the immediacy of the politics and social dynamics of wherever the fuck we are.

A home away from home, free from any history or consequence. Yet providing lasting memories and insight into the human condition. Or, to be fair, dumb drunken oblivion.

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

There is a magical document. Nobody tells you how to find it or make one. But it is the secret key to get security programs – or any program – funded.

It's a good Executive Deck.

The Skill That Nobody Teaches

Let's be honest. Many people in security are not the most social to begin with. We chose security as a career path for a reason, and putting ourselves in the position of the business or a senior executive is hard. Even in business functions, though, this seems a skill you only pick up by witnessing the process. I had the opportunity to do so many times, and had a couple of good mentors, fortunately, but that is rare.

The larger organization, and the more senior the executive you are presenting to, the more layers in between will control the process. Executive decks have a format, and these gatekeepers will force you into that – even if you aren't aware what that format is and what the rules are.

There can be so many layers in the organization that your content gets edited outside of your control or even the control of the people you work with to get the content. As your program or team's funding depends on it, the more you can get your slides into the expected shape, the more likely it is you can still control the message. If you are presenting yourself, you will still need to meet the prep team's expectations to get the content approved. After all, you can always be struck off the agenda if they consider the content not worthwhile. You can't make your case if you didn't even get the opportunity.

The Critical First Slide

It is often a challenge to get any time from executives at all. They go through multiple short meetings throughout the day, expected to express an opinion or make a decision. For you, this may be the once-a-year or once-a-career opportunity. For them it's just Tuesday afternoon and after you probably someone else will be making a pitch or present a fire to be put out.

I mentioned these key points in post #5:

• Everything you want to say must fit in 3 slides maximum
• Make sure all that is most important to you is in the first slide — there is a realistic possibility you may not get beyond the first slide
• Realize that many execs are high-speed information absorbers, so get to the point immediately. Make your point in 5-10 minutes

You may get 15-20-30 minutes, but that doesn't mean you're going to get it all. Nothing is easier for an exec than saying 5 minutes before the scheduled end that they have to get ready for the next call. Something can always come up midway. A reschedule may take months. Moreover, you need to leave time for questions and decision making. If you can't make your point within minutes, it is difficult to get a conclusion in the same meeting. That might lead to another reschedule, with the associated delays.

That makes your first slide critical. The second slide is for supporting background information and metrics. The third slide is a detailed breakdown of your request. Everything you need to communicate, however complex, must be in one slide. This is a good structure:

What is the (size of the) problem?	How will you solve it?
Why do I care?	How much does it cost?

Divide your slide in quadrants. In each, in about 3 bullets describe the core message, ideally in sentences of six words or less. If you're like me, and think in paragraphs, rather than words, and have a tendency to add a lot of nuance, this is probably the most difficult part. Nuance is for the verbal presentation (including speaker notes) and appendix.

Grab Their Attention

Describe what the problem is that you want to address. It is important to give a sense of size. If the problem seems minor and not of the magnitude to warrant their attention, they will be inclined to ship it off to someone else.

The “why do I care?” part that follows is really about how much trouble am I/are we in for not doing it. The “we” is the organization or business unit as a whole. The “I” here is the executive, personally. We will care a lot about our particular problem. Executives deal with big problems all the time. You have to register on their scale to get attention. Their perspective is completely different from yours. If you don't get them to see your problem as their problem, you will lose their attention at this point instantly.

One exec that I battled a lot with told me once he appreciated the passion I brought to my topic. I returned the compliment by saying I appreciated that he dealt with a 100 priorities other than mine, so completely understood that at times we would come to different conclusions.

Do You Have a Plan?

Now that you have the executive's attention, you present your plan. You have a plan, right?! Nothing is worse than bringing a problem to an executive, making it clear it is their problem, and not have a plan to fix it. That's why you're here: to show that you have a solution. The fourth quadrant is to show the timeline and cost to put it in place.

It is important to understand here what the executive is looking for. They are looking for the existence of a (realistic) plan. They may ask for details, not so much for those details themselves, but for evidence that you have thought things through, can get started quickly, and that you are competent enough to gamble investment on.

Your cost should be, ideally, within or below expectations of what the executive expects, and of course be significantly less than the financial risk if the problem is not dealt with.

Follow-up questions is also what your slide 2 and 3 are for. Slide 2 is good for supporting documentation, slide 3 is for a more detailed cost breakdown structure, any headcount required, and how you will measure your progress. Any further information can be in appendix slides, or even a project plan, roadmap or other materials that can be shared upon request.

Visuals and Spokesperson

A good-looking deck helps good content, but it isn't a substitute for it. Good visuals and esthetically appealing slides that enhance the message will give a good professional impression, and again will raise the confidence that you can be competent enough with investment that could easily go somewhere else.

It is also important to pick the best possible spokesperson. Don't switch presenters, unless during Q&A when pertinent. The best spokesperson is the one that can deliver the message the best, not (necessarily) the one who owns the project, had the main idea, or did the slides. This is not the time for recognition and ego, it is the time to get the program funded.

The Squeaky Wheel Gets the Grease

An executive presentation can be intimidating. But hiding problems doesn't get you funded. The squeaky wheel gets the grease, whether we like it or not. The art is to squeak without being too annoying and making it clear you have an affordable approach to make the squeaking stop.

Good luck!

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