NOTE: I was recently quoted in a story for NPR’s Marketplace regarding this issue.

For clarity, a software monoculture is when an organization uses a small, standardized set of software, service providers, and/or hardware. The most obvious example is the dominance of Microsoft Windows on desktop and laptop computers. Software monocultures extend to security technologies as well, which is why the CrowdStrike outage was so widespread.

Like it or not, the software monoculture is here to stay. Standardized compute environments are preferred as they are easier to monitor, manage, and secure. The recent uproar over monoculture due to the CrowdStrike incident is a distraction. It avoids the real problem that organizations are unprepared for systemic outages and looking to blame somebody else for their problems.

Marge vs. the Monoculture*

In the early 2000s, my company was conducting a penetration test on a client. One of our scans crashed the customer’s network. After a tense 30 minutes, we got them back online. However, the CIO was enraged and demanded to know why we did this. When I explained that the firewall had a bug that made it crash when scanned, he persisted with his complaints. I reminded the CIO that discovering this kind of flaw is why you conduct penetration tests.

This incident was an opportunity to build resilience into the organization. However, this immature CIO was more interested in who he could blame for the outage rather than how to recover from it. Similarly, every time there is a large outage, social media fills with “thought-leaders” whining about how evil Microsoft is and that we need the government to intervene. The recent CrowdStrike debacle is no different.

Microsoft is not evil. CrowdStrike is not incompetent. Bugs like this are not indicative of some systemic failure. Mistakes happen. The mistake is not as important as how we react to it. Either you view an outage as an opportunity to improve or as an opportunity to blame.

Blaming others for the outage does nothing of value. It merely allows people to feel better about the situation. An outage should be seen as a chance to review response, recovery, and contingency plans. Organizations that had reliable plans breezed through the latest outage. Those that did not struggled to come back online.

More is Worse

Ultimately, monocultures are a net positive. A standardized, uniform, consistent environment is immensely easier to manage, monitor, and secure. This is not a new idea. Standardization has been a driving force in technology since the dawn of civilization. The entire Internet is built on standards. The benefits of a monoculture far outweigh the negatives.

This reminds me of another immature CIO I encountered. The CIO’s security team was struggling to operate their next-generation firewall (NGFW), resulting in numerous outages and security incidents. Consequently, the CIO wanted to purchase a competitive NGFW and run them both, believing that one could monitor the other. In a moment of brutal honesty, I replied: “You cannot effectively run one firewall; why do you think running two will be better?”

This CIO believed that the firewall (or monoculture) was the problem. He also believed that adding more technologies to the environment would compensate for this perceived weakness. Of course, the problem was him (and his team). They were blaming the technology for their own inexperience and ignorance. Unsurprisingly, the new firewall they installed caused additional problems and more outages.

Single Point of Fail

This CIO was consumed with preventing a “single point of failure.” The single point of failure issue is often applied to Microsoft Windows since a single flaw in Windows can lead to systemic outages. There is truth to this. However, it is not a justification for adding complexity to the environment. Making an environment more complex with a diverse set of technologies merely to avoid a possible single-point of failure only creates lots of points of failure. At least with a single point of failure you can identify, remediate, and recover more quickly.

When redundancy is necessary, it must extend to all dimensions of the environment. This is why containerization and cloud technologies are ideal for resilience. They have redundancy integrated into the platforms.

It does not make sense to spend millions building redundancy into a cloud architecture only to entrust its successful operation to a single overworked IT person or single piece of security software (like CrowdStrike). For redundancy to truly work, it must extend to all dimensions of the environment. This becomes an immensely expensive proposition, which makes it unreasonable for all but the largest organizations.

Every organization has single points of failure. They are unavoidable. It is useful to know where they are, but it is not always useful to mitigate them. Rather than implement complex redundant systems, have a robust set of contingency plans to rapidly recover in the event of an outage.

Overcoming Monoculture Anxiety

The CrowdStrike incident added a lot of stress and anxiety to already overworked IT teams.  It is natural to seek out ways to prevent the next incident.  However, the answer is not to deploy more technology (necessarily.)  CrowdStrike is an effective security control.  It is effective a lot more than it crashes.

A more reasoned response to this (or any other outage) would be:

• Review your system backup and recovery processes. You should be able to restore any system, anywhere in your network to a previous state on a moment’s notice.
• Consider technologies that provide rapid recovery. Microsoft has many of these embedded into the operating system.  There are plenty of third-party tools as well.
• Have a contingency plan for effected workers. One suggestion is to quickly spin up cloud-workstations in AWS or Azure that employees can use to continue working.
• Have a communications plan. When systems are offline, employees, customers, and partners need to know what is going on.  Have a way to contact everybody with a unified message.  This message should come from senior leadership (like the CEO).
• Perform an annual “table top” exercises with your teams on how they would respond to an outage. This prepares people to handle the situation.
• For mission critical systems, migrate them to containerized platforms that can automatically reset to a known good state. For security, consider moving target defense technologies.

Conclusion

Outages are inevitable. No amount of technology, people, or processes can overcome this. Rather than complain about Microsoft’s dominance, work on ensuring that when those Microsoft systems go down, they can be recovered and reset quickly. Microsoft already has integrated functions in Windows to support this. Moreover, numerous third-party companies provide rapid recovery software.

This most recent outage demonstrated clearly which organizations had dependable contingency plans. Those that did were up and running in a few hours. Those that did not spent time blaming others rather than fixing their problems.

The monoculture is here to stay. How we react to it can change.

* This is a reference to the Simpson’s episode, Marge vs. the Monorail.

The post The Software Monoculture Is Here to Stay appeared first on Zenaciti.

A few years ago, I predicted that the large cloud service providers (CSP), like Azure, are slowly consuming security products and offering them as services.  This was not a prediction, but rather pointing out the obvious. This had been going on for years, starting with AWS offering web application firewall as a service.  With each passing year, the CSPs have expanded their security services.  For example, Microsoft added Sentinel, GCP built Chronicle, and AWS added GuardDuty.  Microsoft is particularly aggressive in bundling their security tools and capabilities into Azure and Office 365 platforms.

The CSPs already have the tools. They have the knowledge. They have the ability. Why not give customers free security as part of their hosting costs?

The free offering should be a complete defense in depth platform: endpoint security, vulnerability management, network firewall, intrusion detection, web application firewall, data encryption, identity management, and centralized log monitoring.  Unite them into a single console, offer them for free to any customer hosting workloads on the platform.

Why should they do this?

A Case for Free Cloud Security

While there are many reasons for free cloud security, there are three compelling ones that deserve attention:

1. It Would Show a Commitment to Security

CSPs are increasingly entangled in the security of their customers.  When there is a breach, customers are quick to blame the CSP.  AWS for example has a long history of being blamed for leaky data buckets, which is entirely unfair since they do not control the access rights.  Offering a complete suite of security tools, for free, would demonstrate a commitment to ensuring customers host their workloads securely. It also would allow the CSPs to integrate security tools into their templates and blueprints.

2. It Will Accelerate Cloud Adoption

Large and small companies routinely cite security concerns as a primary reason for not migrating to the cloud.  This 2019 story validates that thesis.  Offering free security would encourage a lot of companies (even enterprise sized ones) to move to the cloud.  Free security lowers the burden of relocating workloads to the cloud. It allows companies to more quickly build secure environments that can host sensitive workloads.  It may also convince companies that fear cloud adoption that it is safe.

3. It is Good Business

Free security would not come cheap for the CSPs but it would increase billings.  One of the things I noticed when I helped customers move workloads to the cloud, was that security drove additional spending.  Once an organization was comfortable with the security of their platform, they were comfortable moving more workloads into the cloud.  Moreover, there was a natural sprawl of usage. In one customer, I recall their AWS billings more than quadruped when we deployed strong security controls.

Free security makes cloud hosting more attractive to customers.  It also reduces a customer’s expenses. That frees up budget for more cloud spending on instances, databases, and other services.

Drawbacks

What about the existing security vendors?

Their business would erode.  Stand-alone security vendors like Crowdstrike, Qualys, or Palo Alto Networks would see some lost business. This means they would need to adapt to offer more advanced security capabilities beyond the baseline.  That is still good for the rest of us.

Can we trust CSPs with security?

We already do.  Our data is already at these CSPs.  You think all those SaaS application subscriptions you purchased are running on some Dell server in a data center?  They are running at AWS or Azure.  I have seen the security operations at these CSPs. They do a significantly better job at security than 99% of the organizations out there.  They have to, otherwise customers would abandon them.

It Creates Platform Lock-in

That already exists. For all the talk of “multi-cloud” strategies, extremely few organizations implement them.  Multi-cloud strategies are insanely expensive.  This would not fundamentally alter the lock-in issue.

There is No Way AWS Could Compete with the Likes of Palo Alto Networks

They do not have to. This is not about building the best security tool possible. This is about building a capable set of tools that can deliver a reasonably acceptable security baseline. Again, think Microsoft Defender. Is it the best AV on the market? No, but it is better than nothing.  For smaller to mid-sized organizations, it is completely adequate.  A free cloud security platform would offer an adequate set of tools, not top-of-the-line stuff.

What is Good for One, Is Good for All

There is one more compelling reason for cloud providers to offer security for free – it is the right thing to do.

Decades ago, the Bill and Melinda Gates Foundation began funding immunization efforts in developing nations.  Eliminating curable diseases was not only good for the people, it was good for all of us.

Microsoft did something similar.  It began bundling Defender Antivirus with Windows. Initially the product may have had weaknesses, but it spread anti-virus to the masses.  Entire strains of common malware disappeared.

Cloud providers are in a similar position.  They could make their platforms stronger and more desirable with a complete, bundled security platform.  Then small businesses, non-profits, and governments world-wide could operate more securely.  Which is good for us all.

AWS, Microsoft, and Google, you can make this happen.  Do it.  Do it for your own interests.  Do it for ours.

The post AWS, Azure, and Google: Make Security Free for All appeared first on Zenaciti.

There are numerous articles out there which discuss this issue. Here is a small sample:

• Harvard Business Review: Boards are Having the Wrong Conversations about Cybersecurity
• CNBC: Cybersecurity Experts Have Become Targets for Board Seats
• Mimecast Blog: Boards of Directors Rising to Cybersecurity Challenge

Many companies have elevated their CISO (or CIO) to report to the board.  This can provide the board with regular insight into the security posture of the company. While the CISO and board both share a governance responsibility, that governance differs in some important ways.

Some of the challenges of having a CISO report to the board include:

• Communication barriers. Board members seldom possess security expertise. They are unlikely to engage the CISO in a meaningful conversation about vulnerabilities, risk management, or compliance.  This communication gap makes it difficult for the board to effectively hold the management team accountable.  It also makes it difficult for the CISO to effectively inform the board on complex security issues.
• Divergent focus. Boards are strategically focused while CISOs must remain operationally focused.  This creates a natural divergence between these two groups, which can further exacerbate miscommunications, misunderstandings, and missed opportunities.
• Reputation bias. Employees of the company, such as the CISO have a vested interest in protecting their reputation. They will overemphasize their accomplishments while downplaying their failures. Do you really think a CISO will come to a board meeting and report that security is a mess and he is failing to do his job?  Probably not.
• Lack of context. Security is dynamic and volatile.  To build an effective strategy, a board must look beyond the company into broader industry and threat landscape trends.  A CISO working at a single company will struggle to bring such perspective to the board.
• Stress. Increasingly, boards are making demands of CISOs they are unable to fulfill.  This is causing a dramatic rise in CISOs resigning to find less stressful environments.

The answer to these and other challenges is to appoint an independent cybersecurity expert to the board as an observer.  This person can serve as a liaison between the CISO and the board.

Let’s assess how an independent expert can benefit the board.

1. A Strategic Approach to Cybersecurity

Cybersecurity cuts across multiple dimensions of a company.  It is a both a technical operational challenge as well as a strategic issue as well.

Including a cybersecurity expert on the board ensures security concepts are integrated into the strategic planning process.  When an executive is championing a new product or feature, the board advisor can weigh in on the potential security implications.

For example, right now many startup CEOs are fascinated with AI.  They all saw the meteoric rise of ChatGPT and want to get a piece of the action.  The problem is that AI opens the door to numerous security challenges.  Any strategic plan must address issues such as data governance, sanitization, and provenance.  Without a clear understanding of these security implications, the board may greenlight a project while also greenlighting a massive data breech.

A security expert on the board can provide context for these issues.  Mostly, they can ask the executive team tough questions about these plans and hold them accountable.  This is a good segue to the next item on this list.

2. Accountability and Independence

Company boards are responsible for overseeing governance of the entire company, not merely sales or finance.  This means oversight of cybersecurity, risk management, and compliance as well.  Unfortunately, board members (such as investors) are seldom skilled at these concepts.  As such, they are highly susceptible to being misled into complacency.

Independent advisors can ask tough questions that a CISO or CIO may be reluctant to ask.  Moreover, an advisor is more likely to point out flimsy excuses.  In my experience, when technical people are struggling to deliver results, they routinely resort to avoiding scrutiny or blaming others for their problems.  An independent advisor can identify these and hold the team accountable.

Independent advisors have greater freedom to uncover truth, thereby allowing the board to hold them accountable.

3. Wading Through Compliance

If you have ever spent time doing security compliance work, then you know how profoundly difficult it can be.  Compliance is an impediment to progress.  It is expensive, time consuming, and fraught with misinformation.  It is also absolutely necessary.  Failing to meet regulatory requirements can severely restrict a company’s opportunities as well as expose them to fines.

Most boards wave off compliance as an irritant.  They task the CISO with the job without an appreciation for how difficult that job can be.  Moreover, the pedantic nuances of compliance create an impenetrable communication barrier, which both employees and auditors can exploit to avoid accountability.

An independent advisor breaks down these barriers.  They can interact directly with auditors and employees to ensure compliance initiatives remain on track and do not squander company resources.

4. Strengthened Incident Response

When a serious security incident happens, the entire organization as well as partners, vendors, and customers will be looking to the executive team for leadership.  Invariably, those parties are going to want to know the board’s involvement.

A security advisor to the board can play a crucial role before, during and after an incident.  Before an incident, the advisor can ensure resilience planning and automation are being integrated into every business function.  During an incident, the advisor can liaison with executives, authorities, and the public to present a united front among the leadership team and the board.  After an incident, an advisor can facilitate a “blameless postmortem” process to ensure the company does not repeat the errors or oversights of the past.

Lastly, advisors can provide valuable contextual guidance with emerging resilience technologies.  For example, one such solution is Moving Target Defense (MTD), which can dramatically improve operational resilience to attack.  However, MTD is still a nascent technology.  An advisor can provide the board and executives with valuable insights from other companies on the capabilities of these new technologies.

5. Building Trust

After years of leading a security company, I discovered a simple truth about security sales: credibility creates trust.  If you want to build trust with security practitioners, you must demonstrate you understand their profession.  A nerdy conversation about PKI or Palo Alto Networks reassures a practitioner you understand them.  When people trust you, they tell you the truth.  Such as how vulnerable the company is to attack.

A board member who calls the CISO to discuss security will only spark panic.  Both their position on the board and their lack of experience fosters a credibility gap with the CISO.  This leads to clumsy conversations that fail to uncover the truth.

Independent advisors with a background in security can credibly interact with the organization’s technical team.  They can gather useful insights and report these back to the board.  When organizations deal in truth and trust, they can address problems more effectively and accelerate strategic plans.

What to Look for In an Advisor

If you are ready to appoint an advisor to the board, there are five key skills you should seek.

1. Executive Experience. The person must have experience as a c-level executive in the past. Preferably as a CISO, CIO, or even a CEO.
2. Hands-on Security Knowledge. The advisor must possess operational security expertise.  They must be able to engage technical people in credible conversations based on their experiences.
3. Listener. The ideal advisor listens first and then provides meaningful, relevant feedback.  Do not hire a pontificator who masks their insecurities and inexperience with bravado and blather.
4. Communicator. The advisor must be comfortable and articulate in front of an audience, especially investors.
5. Network. Good advisors have a network of fellow security professionals whom they can turn to for insights that fall outside their expertise.  Moreover, they can call upon that network for recommendations for vendors or auditors.

Conclusion

There are numerous benefits to appointing a security advisor as a board observer.  Moreover, there are ample professionals who can fill this role.

Obviously, Zenaciti offers these services, so we are biased to the value of such advisors.  However, I have watched numerous startups flounder as they ignore the security landscape, sinking deeper and deeper into delusions of “we got that covered.”  Do not allow your company to be run on the whims of hand-waving and hope.  Put a security expert on your board and run the company based on truth and trust.

The post The Imperative Role of Cybersecurity Experts on Company Boards appeared first on Zenaciti.

I am not the only one noticing all these stressed out CISOs. Here are a few recent stories:

• CISOs Have the Toughest Job in the World
• CISOs Struggle to Cope with Mounting Job Stress 
• Average tenure of a CISO is just 26 months due to high stress and burnout (which cites the same report as the first item)
• I Was A CISO for Six Years — Here’s Why Burnout Is Such A Problem 

I spent time lurking in CISO hang outs recently.  I heard a lot of stories that all centered around a common adjective: frustration.  CISOs are under tremendous pressure to keep their organizations safe.  There is too much to do, too little time, and too few resources.  Moreover, the complexity of modern enterprises coupled with the persistent threat of ransomware attacks makes CISO jobs profoundly difficult.

However, frustration is only part of the story.  There is another adjective I heard frequently: hopeless. One CISO summed it up succinctly: “they blame me for everything that goes wrong.”

Yeah, I know how that feels.

Maybe this is why many CISOs get the title Chief No Officer slapped on them?  Faced with hopeless odds of success, it is easier to say no than to fight to make things work.  I used to think CISO that did this were weak leaders.  However, the more I hear them talk, the more I think they are stuck in a classic Kobayashi Maru (a no-win scenario). No matter what they do, they get blamed.

It works something like this:

1. Company hires a new CISO
2. The expectations are ludicrous:
   • Executives and board members expect the CISO to protect the business with absolute precision and perfection.
   • Other departments expect the CISO to implement security without disrupting any existing business functions.
   • Third party vendors expect the company to align with several intricate compliance regimens.
3. The CISO implements a plan.  There are two common outcomes:

The CISO implements effective security controls: 

• • • The controls fail, company gets hacked  > CISO blamed and shamed
    • The controls work, but it causes other systems to fail > CISO blamed and shamed
    • They work, security becomes routine and dull. Executives wonder why the company spends so much on security > CISO blamed and shamed

The CISO is unsuccessful, security languishes: 

• • • Company hacked > CISO blamed and shamed
    • Company somehow does not get hacked, executives wonder why they have a CISO and no security controls > CISO blamed and shamed
    • Company fails a compliance audit > CISO blamed and shamed

5. The CISO quits or is fired
6. GOTO 1

There is no way to win.  Mistakes in security (and technology as a whole) are common.  Since many CISOs rose through the ranks from technical roles not business schools or investment firms, they usually lack the skills to navigate the petty politics of organizations.

When people are trapped in situations where they feel they cannot succeed, they become bitter, resentful, and eventually give up.  Why work hard when you will be blamed for every problem, whether you caused it or not.  I once witnessed a company put their entire environment at risk, because a vice-president wanted to spite the security team for using a different cloud service provider.  Eventually, the CISO tired of these antics and left the company.

It is unsurprising then that many CISOs feel frustrated and are quitting. With that in mind here are some ideas for CISOs stuck in a frustrating job:

• Adapt Communications: Each person you interact with has a particular communication style. Take a moment to consider how people will listen to you more effectively.  Some people prefer to get right to the data, while others may require a gentler touch. Remember, you are responsible for being heard.  It is not the listener’s responsibility to understand you.
• Stay Strategic: Play the long game.  Have a plan and stick to it. Avoid getting mired down in petty squabbles. Keep reiterating the value of security.
• Snuff-out the Gaslighting: One-way bad leaders distract CISOs is with irrelevant questions and faulty logic.  For example, they may use anecdotal reasoning, where they recite some situation from their past an expect you to replicate that when you know it will not work.  Listen, show respect, placate where necessary, but stick with your plan.
• Arm Yourself with Data: When the blame starts flying, have data on your side.  Data might not save you, but it is a powerful weapon against the forces of idiocy.  Make sure goals, plans, and commitments are documented.
• Stay Off the Range: Security is an easy target for developers, IT, finance, HR…everybody who needs a scapegoat.  Do not allow your team to be unprepared.  Be on top of your goals, metrics, and plans.
• Hold Vendors and Service Providers Accountable: Do not allow the companies providing you products or services to skip out on their commitments.  If a vendor promises you something, get it in writing and require them to deliver.  This is how you can show strength, resolve, and discipline.  Be firm, do not be a jerk.
• Battle the Bullies: You may have board members or executives who think they are security geniuses because they have money and authority.  These people are often deeply insecure bullies.  Keep your discussions with these people focused on threats.  Talk about the competition, ransomware, hacker groups, and all the catastrophes that will unfold if security is sidelined.  Bullies innately understand threat.
• See and Sell a Brighter Future: It is difficult to scapegoat a person who speaks of a brighter, better, and more prosperous future. While you may need to pound the bullies on the board with fear, spread optimism, vision, and hope elsewhere.  Optimism is attractive.

While I cannot fault anybody for giving up when things feel hopeless, you must take something from each experience that helps you in the future.  You might not make a difference in every place you work, but every place you work, can make a difference for you.

However, I would urge all CISOs to hang in there.  With persistence and perseverance, you can make a difference.  Lastly, make sure you mentor and train others along the way.  Leave your employer in a better place then when you got there.  The people you mentor will support you.

The post What Is Wrong with the CISO? appeared first on Zenaciti.

However, security automation is a daunting task.  Cloud service providers, security vendors, and consultants are all fond of promoting the promise of automation.  Yet, as teams struggle with the complexities of cloud environments coupled with the nuances of security controls, these promises can quickly unravel.  Paradoxically, a key component of security automation success is neither security nor automation, but something far more pedestrian: documentation.

To paraphrase the famous World War II general Omar Bradley, amateurs talk, professionals document.  While talking about policies, theories, and strategies for security automation are a good place to start, at some point all that promise must translate into action.

Documentation is where the promise of security automation becomes reality.  Like any complex task, security automation demands the mastery, coordination, and implementation of a disparate set of tools, techniques, and talent.  On rare occasions, a single person can do everything and keep the details in their head.  More commonly, automation projects engage multiple people, working across multiple tools, all with multiple (competing) agendas.

Without documenting the details, you are entrusting the entire effort to the whims and memories of people, which are notoriously fickle and fleeting.  With documentation, you can unlock some important powers that fuel success.

Documentation creates transparency and accountability

Documentation can be shared, reviewed, and referred to later.  Documentation puts ideas, plans, issues, and decisions into a tangible form.  Moreover, you can hold people accountable to what they wrote or what was shared with them.  It is much more difficult to hold people accountable to what they said, since they can deny it or dismiss it.

As the pandemic has driven more teams to work remotely, old methods of accountability, such as casual hallway chats no longer work.  Documentation is the only way to overcome this loss and promote accountability among leaders and employees.

Documentation can identify confusion and eliminate it

Documenting the technical details forces the author(s) to organize and clarify their thoughts.  When other team members read the content, they may be confused.  This may force the author(s) to reorganize the content.  Ultimately the process of revising the content will help everybody, including the authors, understand the details better.

Many years ago, an employee had an idea for a security automation for the Security Operations Center (SOC).  The idea seemed innovative, but confusing.  After some high-level discussions, I asked the employee to document his plan.  In the process of writing the plan, we discovered that not only did the team lack the skills or resources to build the feature, but that the feature was also financially impractical.  The act of organizing the details into a document exposed the weaknesses in the plan.

Documentation builds upon itself

Once a plan is documented, people can analyze it, alter it, and augment it.  Documents invite improvement.  Implementing and configuring security controls requires multiple iterations of testing and refinement.  If these efforts are documented, future teams can learn from those efforts and build upon them.  Moreover, as automations are encoded into languages (like Terraform or Azure ARM templates), future security experts can update, refine, and improve that code.  Documentation inherently begets improvement.

Conclusion

It is easy to get lost among the alluring promises, strategies, and technologies of automation.  Cloud service providers like Azure and automation tools like Terraform are powerful.  These platforms can accomplish almost anything in a cloud environment.  However, the tools themselves are useless and your talent wasted if all your strategies do not coalesce into functional automations.  Much like logistics were Omar Bradley’s secret weapon to win WWII, documentation is your secret tool to make security automation work.

NOTE: Bradley’s actual quote is “amateurs talk strategy, professionals talk logistics.”

The post The Most Important Part of Security Automation is Neither Security nor Automation appeared first on Zenaciti.

Despite my cynical introduction, I am a fervent believer in Zero Trust. Zero Trust environments are fundamentally more secure and resilient. What annoys me is the hype.  Whenever any technology or technique becomes popular, the marketeers overpromote, overpromise, and overstate the benefits (and understate the challenges).

If you know better, you know that Zero Trust is complex. With that in mind, let’s stick our hands into the Zero Trust hype machine, scrape the marketing goo off the gears, and see what makes Zero Trust really tick.

What is Zero Trust?

While many of you reading this already know what Zero Trust is and do not want to read yet another pandering explanation, indulge me for a moment.

Zero Trust is a ridiculously overhyped word these days that gets slapped on everything including products, features, cloud services, and entire companies. This is where the first problem lies: Zero Trust is not a product, not a service you subscribe to, and definitely not a company. 

Zero Trust is an architectural design approach.  I prefer the word, Zero Trust Architecture (ZTA).  Zero Trust is something baked into every part of your infrastructure and applications.

The alternative to ZTA is Castle Defense Architectures (CDA).  CDA was how most of us built corporate networks in the past: strong perimeter, soft interior.  This typically manifested with a NGFW at the perimeter, with some internal monitoring inside the trusted zone.

Concisely, CDA explicitly trusts some things, while ZTA trusts nothing.  Apple devices are a good hardware example of a ZTA, as are cloud providers like AWS and Azure.

ZTA is inherently more secure because, to state the obvious, nothing is trusted.

Where Zero Trust Comes Unglued

Unfortunately, Zero Trust is difficult to adopt, challenging to maintain, and perpetually locked in a tug-of-war with those pesky humans and their penchant for doing dumb things.  In other words, it is like everything else in security.

Furthermore, Zero Trust is different for application environments versus corporate environments.  To keep things simple, I am going to focus on application environments.  Corporate environments with all their laptops, printers, and other technical detritus face the same challenges, just in a larger scale.

Let’s unpack these three ZTA challenges.

Start Vulnerable

Ever spent time with developers?  These are not people who like a lot of restrictions.  Developers need freedom, and rightly so. Building apps requires the freedom to tinker and test out multiple designs. This makes it difficult to implement the restrictions necessary for ZTA environment in the middle of development.

Most organizations develop applications in “full-trust” environments that have no access restrictions or security controls. Only after the environment is built, do security and DevOps teams attempt to impose security controls on the environment.

This approach creates a positive inclusion coefficient.  That is a fancy sounding way to say it is difficult to find all the holes.  This is because the environment starts in a vulnerable state and to get it to a secure state, engineers must locate all the possible vectors of compromise.  The number of exploit vectors grows in a non-linear manner (possibly exponentially) with greater complexity.

However, if the devs embrace ZTA and make tuning security controls an integral part of the development process this creates a negative inclusion coefficient.  Rather than trying to identify the vast number of ways an environment might be exploited, devs focus on the smaller amount of access rights necessary to keep things running correctly.

However, even if you start with a ZTA you still must maintain it.

Stay Vulnerable

Application environments (as well as corporate networks) are not static. New features, component updates, expanded access, patches, new devices, new employees, additional customers…the list of possible changes is long and dynamic.

This gets us back to that positive inclusion problem.  The more things change, the more difficult it becomes to maintain the complex access rights of ZTA.  If you have ever managed a corporate perimeter firewall, you know exactly what I mean.  You start with everything locked down and secure. Then little by little, over time, access becomes loosened. It starts with some third-party vendor requiring a bunch of weird ports for their crappy software. Next it is an update to some internal system that needs a group of people to have unrestricted admin rights.  Then it is the CEO’s pet project that demands a dangerous “any-any” rule.  In a brief time, the NGFW is essentially useless.

Oh, and incidentally, this is why breaches happen.

To solve this problem, you must have “custodians” of the environment, who can monitor for issues and maintain the security controls.

Now, scan through all that marketing blather from ZTA companies. Do you see the word “custodian” in any of them?  Of course not, because imagine a product pitch that said: Our product will secure your business and give you a tedious job that is profoundly unrewarding, and if you make a mistake, you will be fired and humiliated!

Which drops us into the lap of the third challenge.

Stop Being Human

Humans make mistakes.  I do not think that is a remarkably controversial statement.  Human error is the Achilles Heel of Zero Trust.

Remember back when AWS was getting all that negative press about S3 buckets being public on the Internet? AWS S3, like most of AWS, is a Zero Trust service.  When you setup an S3 bucket, it has no rights.  It starts in a secure state.  Humans must overtly reconfigure S3 to be public.  This happens all the time.  This is how S3 buckets become sources of attacks.  It is not AWS’s fault.  Their service follows ZTA practices. It is the humans operating those services who make mistakes.

Those pesky humans. They create the problems and they also can solve the problems. The answer to this is to require identity validation at every stage, which is great…except when it gets turned off because of all those pesky humans.

The Bigger Picture

If all this feels depressing, then allow me to quote Gale from Raising Arizona, I’d rather light a candle than curse your darkness.*  There is a way out of this ZTA muck and it does not require robbing a store or putting a panty on your head.

The answer is frustratingly simple and immensely complex: Zero Trust is a strategic business challenge, not a technical challenge.

The technology of Zero Trust is everywhere, inside everything.  If you are making Zero Trust a technology project, then it will probably get watered down and sputter out in the long run.  Zero Trust is a cultural or business problem.  Zero Trust must be embedded into all your code, all your teams, all your people, and all your designs.  You cannot buy a Zero Trust thing, slap it on your stuff, and then proudly proclaim your application as secure.

Your organization’s ability to adopt Zero Trust is more a factor of your organizational culture than what technologies you use.  If your leaders truly embrace Zero Trust vision, specifically the need to automate everything, then you have a good chance at being successful.  If you are still doing things manually and/or allowing vendors to control your architecture, it will be a rough ride.

Getting Past the Zero Trust Hype

So now what?  To get past the hype, you need to honestly consider some key prerequisites to Zero Trust:

• Is your environment in the cloud (AWS, Azure, etc.)?  ZTA is practically impossible in old-school on-premise environments.
• Have you automated your architecture? Build, test, inventory? Better get on that HI!  No point in twiddling with ZTA tech until you have a fully automated environment, because manually managing access rights is a nightmare. And you might be carried off by a twister.
• Have a bunch of third-party dependencies in your environment. Do you know exactly what access they need?
• Do you have real-time asset inventory? This must be an inventory of everything, and not some spreadsheet on the IT admin’s desktop.
• Can you automate the testing of access rights, vulnerabilities, and configuration? This cannot be dependent on some unhappy dude clicking the correct buttons at 4:00am.  It must be automated.
• Is user (and system) identity validated at every point in your app data flow? It must be.
• Do you have a team of people who can effectively run the environment 24/7? Why burn zillions building an app only to put it in the hands of underappreciated, overworked, and chronically devalued IT admins. The people who run app environments are as important (if not more so) than the people who build them.
• Is your leadership have the vision to adopt Zero Trust?

That last item is the clincher.  Your team (and leadership) must commit to ZTA.  Do not waste your time twiddling with Zero Trust technologies if your team will bypass the security and cut corners at a moment’s notice.

When you peel back the Zero Trust hype what remains is something non-technical: vision.  Does your team have the tenacity and commitment to build, maintain, and monitor a Zero Trust environment? Is security engrained into your culture at every level?

If so, then go get some of those cool Zero Trust tools. If not, then all the tech, subscriptions, fancy words, and promises in the world are not going to plug those holes.

Well, okay then.

* Yeah, I know. That quote is originally from Eleanor Roosevelt and not Gale.  Raising Arizona was funnier.

The post Beware of Zero Trust Hype appeared first on Zenaciti.

Consider something as common as television. For decades, there were only 3 channels with limited content. This was because broadcasting TV signals was expensive and highly specialized. In the 1980s, cable TV standardized the transmission of signals over coaxial and fiber cables, unleashing innovation and deregulation. Today, we have hundreds of channels and vast choice. Standardization (as well as technology improvements) made that happen.

From shipping containers to application containers, standardization is a necessity for innovation and scale.  

Non-Standard Security

For all the innovation in information security, there is little to no standardization.  There are some technical standards, like STIX and TAXII for intelligence sharing.  However, these are limited in their scope.  Security has no standards to govern the configuration, documentation, and auditing of security controls. This is where all the problems live. 

Now, you may think that compliance standards, like PCI or FedRAMP provide a standardized way to implement security. Yeah, no. Compliance frameworks describe an ideal state in generic terms.  Compliance tells you that you must have a control, it does nothing to help you deploy, configure, manage, or audit that control.  Furthermore, it is (relatively) easy for an organization to skirt around compliance requirements and still pass an audit. This is because audits remain a subjective assessment from a person.  

The sheer vastness of the security technology universe also complicates standardization .  Take a moment and visualize the vendor expo at RSA Conference or BlackHat. What you see are thousands of security vendors. Yet, each vendor only solves a fraction of an organization’s security needs.  SIEM vendors focus on logs and analysis needs, endpoint security defends against ransomware and viruses, GRC vendors create work for people. Each vendor only plays one part in an organization’s entire security program.  Nothing holds this mess together.  

What we have is a chaotic mess of security tech with no standardized way to configure and validate security controls. Consequently, security is entrusted to people who make mistakes and vendors who have agendas. 

This mess has real world implications, namely breaches.  The root cause in every breach is misconfigured or missing security controls (which ultimately is human error).  The recent Colonial Pipeline attack was the result of attackers stealing a single password to a dormant VPN account.  Multi-factor authentication, robust network malware, stronger endpoint controls, and zero trust access would have all worked to stop this ransomware attack cold.  However, those controls either did not exist or were not configured properly. There is probably some former security person from Colonial Pipeline furiously posting to Twitter: “I warned them this would happen, but they ignored me!!!” 

If there was a standard way to implement, configure, and validate security, then an organization like Colonial Pipeline could have implemented all these appropriate controls without depending on people to do it correctly (which they obviously did not).  They could simply follow a script. 

However, I am not suggesting eliminating or consolidating all those security technologies.  Rather, I am suggesting a standardized way to configure and validate security controls. Or in other words, a universal “language” that abstracts the configuration, validation, and documentation of security controls from specific vendor tools.   This is similar to how Hashicorp’s Terraform, AWS’s Cloudformation, or RedHat’s Ansible work.  These are languages (or platforms) that build and configure cloud services and infrastructure.  While they can play a part in security, they are not specifically for security.   

So, why not a security language?  Let’s take a look at what this language could be. 

Introducing SeCON?   

For lack of a better name, we can call this proposed language SeCON (security configuration object notation.)  At least until somebody comes up with a better name. 

So what would this “SeCON” language do? 

• Define a Dictionary of Security Controls:  SeCON would establish a standard set of security controls that any organization can use, such as endpoint security, firewalls, SIEMs, vulnerability scanners, and so forth. 
• Configuration: It would have a common way to define how a security control is setup and configured.  Things like IP address, DNS names, authentication methods, and certificates. 
• Policies:  It would have a common language to define policies for security controls.  For example, it could have a native set of firewall, routing, and scanning type policies.  Since this may not be sufficient for the universe of security tools, it could also offer a way to embed native configuration language. This would allow the language to accommodate the unique policy or configuration aspects of each tool.    
• Documentation:  SeCON would also provide a method to document the control’s configuration.  In the same structure where configuration and policies are defined, there would be text structures to attach how the control is configured and why. 
• Testing: Lastly, there would be a way to read a configuration file and then test a specific instance of a control to see if it meets the configuration parameters.  This provides a “closed loop” system where the same language that configures a tool, also has the power to validate that configuration at a later date.   

More Barriers

Obviously, this standardized security language would have some significant hurdles to overcome.  Here are a few to consider.   

• Adoption:  Vendors would need to adopt their products to accommodate this language.  However, if a vendor publishes an API, then it would be relatively simple to map the language to specific API commands. 
• Platform: SeCON would need some platform that can execute all these rules and commands.  Ideally, cloud vendors, like AWS could adopt this language into their existing scripting languages like CloudFormation.  However, I am sure there are some technical details I am not considering that may make this difficult.
• Resources:  Standards such as this require a lot of work to define, build, and promote.  To make this a reality would take money and backing.  Support from cloud service providers or standards bodies like NIST would be critical to success.
• Complexity:  This is stating the obvious, but security is complex.  Its not as simple as provisioning a virtual machine or a container.  It is this complexity that makes a language like this necessary. 

The Promise of SeCON

I admit, this language is merely an idea…and possibly an outlandish one.  However, I remain a firm believer that the root cause of all security problems is configuration.  Ransomware attacks are successful not because their malware is particularly innovative.  Rather, organizations continue to rest the security of their company on the inconsistencies and inadequacies of people.  If we can close that gap, it will become more difficult to exploit vulnerabilities because there will be fewer of them in the first place. 

The promise of a standardized language for security would also mean decoupling security configurations from the idiosyncrasies of each platform.  It would not matter whether you had a Fortinet or a Palo Alto, McAfee or Crowdstrike.  If they all worked with the same language, you could standardize across them all.  This would give you, as a user of those technologies, greater freedom to change to a different technology without the arduous cut over from the old tech to the new one.  This is no different than how technologies use Bluetooth, TLS, or NTFS.  It does not matter what brand of tech you have.  They all conform to the same standards. 

The real benefit is the standardization itself.  Once security is standardized, it can be applied universally, consistently, and deviations detected quickly.  Using a single tool, you could theoretically deploy, configure, monitor, manage, and document your security infrastructure.  As your enterprise expands, you can use the same standardized language to modify your security infrastructure. 

A standard security language could deliver massive scale while improving the consistency of security controls. 

Conclusion

If security is ever going to get ahead of the threats, we must stop twiddling knobs and relying on humans to configure everything properly.  A standard security language could revolutionize how security is applied and managed.  It could finally make sense of the messy vendor space. 

What do you think?  What am I missing?  Share your feedback here, or you can always email me at andrew.plato@zenaciti.com.  

The post Standardizing Security appeared first on Zenaciti.