First, it’s good to see we’re talking about security as a state of the business to be invested in, rather than Fear-Uncertainty-Doubt (FUD)-driven dialogs. Supply chain, ransomware, and AI were topics as previous years, but none felt like we’re jumping into the deep end. Rather it felt like, hey, these things are here to stay, we need to learn how to deal with them.

Of course, vendors are always going to lean into scare tactic messaging. In the vendor hall, the messaging was much more FUD-based than on stage. I’m not sure it was warranted. The level of panic around dollars vanishing, money being tight, budgets going away, was continual. 

But we’re not seeing huge swaths of dollars disappear. Money is more expensive: interest rates are up, so money gets tighter. VCs loan less, and so less is available for startups. But this disproportionately affects Silicon Valley. We’re not seeing corporations post huge losses. We’re not seeing huge layoffs after the layoffs in Silicon Valley. 

Sure, total tech spend in general, and across AI and data is being hit pretty hard. But this is mostly because organizations didn’t really get the ROI they expected. The data science-y things they did were too fragile and required too much support in most cases for them to get the scalability and the ROI that they expected. 

We’ll definitely see a reduction in overall IT spend, but I don’t think we’ll see large-scale drops in security spend, mostly because we remain on an uncharacteristic uptrend. I think we’re likely to see a three percent overall improvement, down from seven percent, but not going negative. Most companies have underspent on security year over year, and managing that is still going to be high priority.

Another cool theme I’m really happy to see is a real look at standardization frameworks. NIST and MITRE, academically, are very, very good but they don’t really align with how we implement, what we do, or what vendors produce. It’s almost an after effect. 

A vendor creates a solution that feels innovative in the space, they produce a product to answer a challenge. Then afterwards, they go, we think this fits in NIST this way, same with MITRE. “This solves section 5.1.,” etc. It doesn’t really, but that’s the closest they can find. 

This square peg, round hole situation ultimately doesn’t serve customers very well but the blame can’t be all put on the vendors. Honestly, I don’t think cyber security for most companies is yet a truly strategic initiative. It still feels like we’re under attack, batting down the hatches, everybody move as quickly as possible. So, while vendors are talking FUD, organizations aren’t helping themselves. 

In response, we need to start seeing security as a tech leadership strategy. The CTO running software development cannot escape security as a strategic imperative within the context of what they do. The CIO has likely been better at it for a while. But enterprise architecture-level security conversations are where organizations are going to find the most improvement.

What are your global standards? Do they make sense? Do they handle the challenge? And are we thinking about these things in a way that is cohesive and coherent and defensible, and considers both the state of the market and the capabilities of the organization? 

This brings to workforce. It’s easier to hire IT people and cloud people right now, but security is still a nightmare, right? So thinking about what the impact of any change will be to the very people that have to run it, I think is going to be really important. 

Any good reason to stray away from leaping towards a technology that may look cool or interesting, because the workforce transformation necessary for some of these tools is never insignificant. It may range from low to high, but should always be a consideration.

I would also say if you’re doing application modernization or cloud native, security needs to be front and center. And I don’t mean it needs to be front and center because it’s more important than software development. 

In cloud native you’ve probably figured out the service mesh-y components, and you’ve probably figured out your containerization strategy. But software development teams need to start focusing more and more active energy on learning and understanding security and networking. 

Within cloud native, network and security go hand in hand. What bothers people that developers work with is the lack of understanding on how these work, and I would recommend investing time on both. I did a webinar recently where I recommended that DevOps engineers get the equivalent of a network plus or CCNA education, or that level.

Given that it’s hard to find security practitioners, the company InfoSec really interested me this year. InfoSec does training and certification for security analysts, but now also have a placement agency. As part of the placement, they will do the certification. So, if someone says something on their resume, you know they’ve been tested and certified to have it.

Additionally, let’s say you need 10 people today, your budget’s a little bit low, and you want to grow them over time into positions, Infosec also have an ‘on-the-job training’ program where they place them immediately, start a training program with them.

They come in at a lower rate, train over a year or two years, and get raises throughout? Your cost matches their capabilities, but you get people right away, and they get to grow and evolve with your growing and evolving security practice. We didn’t talk about pricing but we did discuss how important it is for them to be competitive with other agencies.

A few other companies jumped out. Nokia, for example, who took a neat view of where they sit in the market, effectively saying, telco is where we specialize. A company that can say, “This is our market, it’s narrow, and we want to focus on it,” gives me a lot of confidence. 

OpenText continues to surprise me: a company that could be monolithic and hard to work with, really seems focused on not being hard to work with, on buying good products, connecting them cohesively, and delivering an outcome that’s useful and workable for organizations. They tend to skew towards the large side of the mid-market, which is a good place to be. 

I liked the way SyxSense approaches unified patch management, WIB’s technologist-driven approach to API security, and Keeper’s rapid delivery against its roadmap for password management. HackerOne’s penetration testing as a service has a lot of value, especially if you combine it with a bug bounty program, and Splunk (not the same company it once was) is worth checking out for SIEM. 

Overall, the conference was about getting the job done – which means thinking about security strategically rather than rushing round shutting stable doors. Instead, making security a business conversation, which will engender the right conversations, the standards, and the right products from the right kinds of vendors. 

If you’re responsible for security strategy, you can consider this market shift and how it affects your organization, and look into how standardization frameworks align with your company’s needs. In terms of concrete actions, I recommend you evaluate the impact of workforce transformation on your employees, and consider how to cross-skill and upskill for the multi-cloud world. 

RSA was a fantastic conference, and I plan on logging in and watching as many of the sessions as I can. Hopefully you found this helpful, and I’ll talk to you all later.

The post Themes and Trends at RSA 2023 appeared first on Gigaom.

All mid-market organizations are reviewing how they can make better use of their budgets next year. This starts with the infrastructure you have already paid for and how to get the most out of it. When I talked about sweating assets in a previous article, this really has to do with some cost management – how much I can sweat an asset is how much I can continue for it to run after its ideal lifespan, which for most infrastructure purchases is 3 years. If I push that beyond 3 years, I’m now sweating the asset. 

What I want to think about is, where is a good place to do that, and where’s a bad place? Most infrastructure is fairly reliable. That being said, with the infrastructure that I have on Prem (and I’m never getting rid of all of it, even if I go to cloud first), I still have to run a network. I want to think about the kinds of categories of things that I would say are ‘sweatable’, and you could put them in Tier 1, Tier 2, Tier 3.

So, Tier 1. These are things I cannot sweat. The big one is my Tier One Storage. If I’ve got a database, I probably don’t want to sweat the storage as I’ve got that business-critical database, I really need to be on top of it. So that’s a place where I’m not going to want to sweat that investment. 

Tier 2 are things that, well, my business is going to continue to operate well if I use these beyond their three years. Maybe I can get 5 years out of them. For example, servers: I don’t really want to sweat these, but at the same time, I’m not necessarily using all of my CPU, really working that piece of hardware. The likelihood of failure doesn’t drastically increase between 3 and 5 years, so it’s okay to sweat that. I probably don’t want to sweat up to 7. That gets a little risky. Reliability issues increase after five years. Even things like fans failing can become a huge maintenance problem. 

The network goes into that Tier 3 bucket when it comes to non-security components of my network switches. Routers. Those I really should have no problem sweating into this kind of 7-ish year range. Where that becomes problematic is if I’m getting into capability issues, for example, security. Or capacity issues, where I’m pushing more network traffic than the switch can handle. Let’s say we have 10G at my core, or 40G at my core, and I’ve really pushed beyond what the 10G or 40G can really handle. 

As you look at both Tier 2 and Tier 3, as you start to sweat those beyond what the manufacturer considers to be the standard lifespan, you’ll find your first party support costs go up. For switches, if your manufacturer still allows you to get access to firmware, you might consider third party maintenance. First-party firmware is a must: a lot of manufacturers restrict your ability to get current firmware, which has a direct impact on how secure those devices are. 

That works for servers as well. If you can’t get current patches, if you can’t get current drivers, at the very least, you’re going to miss out on security updates. You’re also going to miss out on any stability and bug fixes. So really read the fine print. Make sure that you stand up on that. 

As part of this exercise, I would do some significant contract reviews: it may be worth engaging a company to make sure that you understand what your total spend is, and look for potential to consolidate across the organization. Then you can start doing some master services agreement (MSA) negotiations and contract negotiations to really drive the price down. 

Especially in endpoints! We find a lot of organizations think their spending is anywhere from 40 to 60% of what their actual spend is in things that have been distributed out into the organization for buying power. The ability to consolidate that and say, we’re going to buy all our endpoints from Dell, Lenovo, HP, Microsoft or whoever, and then go to that vendor and negotiate an MSA with discount levels. This can be a significant cost saving. 

The other thing that you should look at is vendor/partner consolidation. You will likely have more vendors than you need, so which ones are really providing distinguished value back to your organization? Which are really helping you think about your business and providing technology as a business asset? If you start consolidating to those, first you can lower the chatter that occurs, but also, second, you can leverage the power of your wallet and get more value from those relationships. 

I would recommend fixing on three vendors. I don’t think you should consolidate any lower than that. Three gives you the ability to do some competitive pricing when necessary. It makes sure that you have a wider gamut of options when you’re looking at products. Higher is okay, or you may not have the time and patience to entertain three vendor relationships, so less is also a possibility. You have to make a choice for yourself. 

These questions don’t go away with Cloud. The first thing to remember is, Cloud should not be arbitrary. By which I mean, it’s okay to have a ‘cloud-first’ strategy, but it’s not ok to have a ‘cloud-only’ strategy. This tends to go poorly. Cloud-first is when the first thing I do is look to the Cloud and say, is this the right place to run this workload? Is the Cloud really built for this? And does my business require the things the Cloud provides? 

Two things should push you to the Cloud; the first being a reduction of technical debt, which means all the shortcuts that were made in deployment, that now cost you in performance, capability, flexibility, or simple maintenance. So, if I deploy this thing to the Cloud, can I do so in a way that reduces technical debt? Am I going to be on the newest version? Can I do it as a SaaS, where I no longer have the same maintenance level/maintenance requirements, and where the software will not continue to be aged, and the age of that software, the currency, or lack thereof, will become a problem?

The second is agility. By putting this thing in the Cloud, am I going to be able to leverage the agility of the Cloud – either in scalability, or left-right add-ons? For example, will I be able to take advantage of some of the AI or ML tools that exist in the Cloud? Would those things complement this application, and thus give me a far greater capability than I would if I had it on premise?

If the answer to both of those is no, and you think you can go to the Cloud and save money, then that’s likely only true if you’re already 94/95% in the Cloud. What I’d really think about is, is the Cloud the right place to run this workload? If not, do I have on-premise infrastructure that can run it? If the answer to that question is yes, I should have it on-premise. Then we drop back into that vendor-tool-contract conversation. 

If the answer is no, and the Cloud is the right place to run it, then deploy to the Cloud, but the conversation stays the same. There are 270 CPU combinations available in AWS. Have we standardized on those? Have we standardized on how we’re going to consume S3, and specifically which S3 products we’re going to consume? Same for our AI choices and ML choices. Can we apply governance to those things, so that it’s not the overwhelming monster that Cloud can become? 

I don’t think the contract conversation changes, whether it’s on-prem or cloud-based. There’s a lot of credit card AWS within an organization. So, can we consolidate that, and enter into a contract and take advantage of contractual discounts? As a customer, can we take advantage of some over provisioning during our contract period, without incurring an increased cost? This is only available on an enterprise agreement, so are we large enough to have an enterprise agreement with AWS or Microsoft?

You can see the relationship between this and asset sweating, tiering. When I’m going through that tiering exercise, I’m also exposing the criticality of the application and its underlying infrastructure to my business. By determining what’s critical to my business, I can also see what is going to benefit from the resilience and elasticity of the Cloud, early, first and foremost. If I can’t sweat this infrastructure, and it’s coming up for renewal, and it’s a significant buy, is running on-prem still the right way to do that?

I also want to consider whether my access patterns have changed. Over the past three years, everyone went home and started to work, and many organizations are finding that productivity is the same or better, or the differences are negligible. But employees really see that flexibility is a huge benefit. Meanwhile we’re seeing in the news how companies are calling on employees to come back to work in the office, and they are seeing a lot of resignations. 

If you’ve looked at that and decided to keep a large percentage of people working from home, it’s likely that driving people to a central data center to access an application may not provide the greatest experience, since you don’t control their last mile network access. It may be worth looking to the Cloud to improve that experience for your distributed workforce. 

This is all about getting in shape, ultimately. Tier your assets, sweat your assets, and move workloads to the Cloud where it makes sense. Most of all, get your vendors in shape, whether they’re on-prem or Cloud, otherwise, you’re just going to be paying more for things you don’t need or which can be discounted. Don’t assume the status quo is your friend, that’ll just cost you money, and nobody can afford to do that. 

The post A three-point plan for mid-market technology cost saving appeared first on Gigaom.

If you haven’t been investing in security for the past 5 years however, you’re going to be coming from a place where you’re behind, and there’s no way to play catch up that doesn’t involve spending money. You may end up having to make a 1 year spend increase to play catch up in a way that’s going to really show value and bring you into parity. So, how to approach this, given that budgets are getting tighter?

Start with self-assessment and existing tooling

My recommendation would be to start with the NIST self-assessment for maturity and security, and really see where you place. I would aim (as a good target) to be in the 2.5 to 2.9 range. 3 would obviously be good, but if you’re below that 2.5 to 2.9, you are going to have a tremendous amount of catch-up. 

The good news is, you have some low hanging fruit to go after. 3 is a significant maturity of space: as we get into the 3’s, we’re more focused on auditability and repeatability. If you’re in the high 1.5 to 1.9, I’d be looking for some repeatable services that you can take advantage of, to push your maturity forward and really get a set of eyes on the space, to make sure that you don’t have any big holes already sitting in your environment, which is another dangerous issue. 

One of the things that attackers do—think of them as freelancers—is, they’ll penetrate an organization, but make no changes. They’ll simply see how far they can go in and document it, then they put the exploit up for sale. Think about it like a business exchange that says, hey, I penetrated this far into this organization, here’s a profile of the organization, and then they sell it to you on the street corner. So, if you’re in the low to mid-high 1s, I would really start looking at: is this something that has happened? Is there something I should be aware of, like a historical breach that went nowhere? 

Then, you’re probably going to need to spend some money on securing your edge, your firewalls. This part of the architecture tends to be a little old. Are all your firewalls currently under maintenance? And maybe they don’t have all the features that you need, turned on and working. 

Then I’d also probably be looking into Zero Trust Network Access, to close out some of the security issues there. I’ve seen a lot of VPN penetration in recent times. Especially those that don’t have a thorough use of multi-factor authentication (MFA), or where their MFA is easily defeated. That’s part one of the security conversation. 

Next, look at people – inside and outside the organization

Where I want to focus next is, it’s incredibly hard to train and retain people. I say it in that order, because if I train them, I’ve made them more valuable in the market, and security is being poached like crazy. So, I want to think about where am I doing that, and how am I doing that with people? I tend to advise, and approach it as a CXO, as follows: if no tribal knowledge is required for the role or for the function, I want to outsource the function.

I want to outsource the function not because I want to reduce my headcount. I’m generally short of people, so that’s not likely. But if I can use a managed service, maybe I will have four people that I can offload some work from. Those four people are hard for me to retain, and if I lose one, I’ve lost 25% of my capability in that space. A managed shop will have four hundred people: if they lose ten people, it’s not going to disrupt their ability to deliver the service to me. 

Consider this versus those things that do require tribal knowledge, like understanding how my business operates, what my business does, and how operations work inside my company. That’s really where I want to focus my people. Where you want to start, where you want to retain people, and really focus them, you can consider as the G of GRC (Governance, Risk and Compliance). I would be investing in that, probably 40% investment (out of my budget). There’s only so much training I can give to my people, only so many people I can hire. So, any person I hire is not a one-time investment, but a rather enduring investment. 

I want to make sure that I own the architecture, and the design, and the people that interface with legal, and people that interface with operations, and the people that have developed a softer touch and are embedded inside my organization. I don’t necessarily want to own the people that monitor my SIEM or monitor my firewalls and my firewall activity. I want to outsource those things to providers that are really good at it. 

Managed security providers can see traffic on an incredibly large scale and can notice traffic patterns that we’re not able to see because our data set is too small. Small data sets in security hurt you. They don’t help you. I want to leverage massive data sets. And so all of that says, what I’m looking to do is build an ecosystem of talent, and that’s both talent inside my organization, and talent outside my organization. 

If I’m looking at spending 25 – 40% of my budget on managed security services, they tend to come along with software licenses: if I outsource SIEM, I’m probably not going to maintain my own SIEM. So, if I’m currently paying for Splunk say, I want to look at my outsourced service and say, what are you using for a SIEM? How is it licensed? Does it make sense to leverage my Splunk, and if not, how do I mitigate the enduring cost of a contract for a piece of equipment I’m not going to use. If I’m in a 3 or 5-year contract. I want to look for a SIEM that will leverage the tools that I have currently, without increasing my contract costs, knowing that I’m going to seek to not renew moving forward. 

So that’s 40% investment in people, 25-40% in services. That leaves 20-35% in new tooling, depending on its current age. For example, Zero Trust Network Access is going to be a new spend, as are new firewalls. ‘Protecting the edge’ is likely to be a particular spend point, upgrading from an old endpoint protection software to something more modern and centrally controlled, potentially managed.

Bring it together – with timing based on contract renewals

Costs are not necessarily increasing but budgets are shrinking. What we’re seeing globally is that budgets are going up about 4%, which is actually a shrinkage in budget considering we’re seeing inflation increase by about 8.5%. Plus, we’re seeing employee costs increase by 15%. So, even with a 4% budget improvement, you’re actually sitting much closer to about a 12% loss overall. Meanwhile, a lot of the large manufacturers are still dealing with long supply chain issues, in some cases greater than 12 months. 

It’s challenging because the job’s not getting easier: security requirements are becoming more complex, and the number of things we’re being asked to do is not getting any less. So I’d really be looking at, where are tangible places I can take my green field, my new security additions and new capabilities to manage the organization? Do I have a good strategy around how I’m going to leverage those and measure an ROI? If not, I’d consider delaying them. 

If a clock expires and it’s time to do a renewal, but I’m not really going to get to see the replacement for a year, it’s the moment to think, is now the right time to execute on that renewal? Do I really need to make planning headspace, and operational headspace, for things that I’m not likely to see for 12 months? Then, are there some things that I could pull from next year’s budget? Are there some things I can pull from 2024’s budget into 2023, if I’m not able to execute on other things? 

When it comes to contracts; if I’ve got tools and services expiring in October, I should be negotiating for those in January. If I negotiate in January, first, the ability to renew early provides some relief for the vendor that I’m buying from; and second, if I’m not going to be able to negotiate terms that I find to be advantageous for myself, it gives me nine months to come up with an alternative plan.

That’s the conversation I’d be having now, so I know where I’m going to get better terms, and lock those things in. I don’t need to review those decisions today. Where I’m not getting better terms, those are where I want to focus. And meanwhile, here are some green field projects: we’ve got good potential ROI and really want to return the value to the business, but I’m not really comfortable I can answer these questions with confidence. These things I want to delay, and push off their cost right now, until we can.

Budget management’s going to become a bigger thing in 2023, and my expectation is 2024 won’t get any easier. Like in 2021, and 2020, we said, “2018 sure seems like a bit of a party compared to today!” But considering your existing portfolio, managing the people who bring the most value for their tribal knowledge, and focusing on contracts that need the most attention in the next 12 months, offers a way forward.  

The post Cybersecurity in the mid-market: Playing catch-up in a cold budgetary climate appeared first on Gigaom.

My recommendations for the mid-market coming up to the end of the year, going into 2023, and doing your annual planning?

Cloud strategies are one “big picture” topic that the mid-market really needs to focus on

How should mid-market organizations think about their move to Cloud? And where are they going to see the biggest bang for their buck? A lot of what we talk about in the cloud is really built around hybrid and multi-cloud, and neither is necessarily where the mid-market is employed to really take advantage. Multi-cloud is expensive. Organizations must have people that understand the intricacies of the individual clouds and then build to an abstraction layer to be able to really take advantage of those clouds. 

So, really, they need to pick one cloud vendor, and really focus on increasing their maturity and improving their capabilities with that cloud vendor, and on the resiliency that makes the most sense for how their business runs, and what their reasonable tolerance for outages is. 

The next topic is what I like to call infrastructure, or tools, “sweating” 

This really has to do with some cost management – how much I can sweat an asset is how much I can continue for it to run after its ideal lifespan. The ideal lifespan for most infrastructure purchases is three years. If I go beyond three years, I’m now sweating the asset. What I want to think about is, where is a good place to sweat an asset? and where’s a bad place to spend an asset? I want to think about the categories of things that I would say are sweatable, from those I cannot sweat to things I can really extend beyond the 3 years.

This is across servers, storage, and networking. For each, make sure that you can still get the software updates. You can’t get current patches, if you can’t get current drivers, at the very least, you’re going to miss out on security updates. You’re also going to miss out on any stability and bug fixes. So really read the fine print. Make sure that you stand up for that.

Then I would focus on security, which I would break into two pieces

The first is – the mid-market is going to continue to be a primary attack sector for ransomware, mostly because they simply have less money to throw at security. The more you spend, the harder you’re going to be able to penetrate, even if the target is ultimately larger. These days, ransomware gangs are, in fact, running their operations like a business. 

So, what you really need to think about is, am I investing properly in security? What I would look at is, am I investing, let’s say, the half a percent of my global turnover in security that I should be? And have I done it for the last five years? If the answer to either question is no, you really need to improve your security spending. Unfortunately, it’s not like you could just raise it half a percent, and that would be ok. it’s not really going to get you the result because you’re going to have to play catch up quite a bit.

The second security piece is that API Security is going to become an increasing problem. I’d start looking at getting your arms wrapped around, what APIs do you take advantage of currently? How do you access those APIs? What is their intended use? And really start documenting. We estimate that organizations underestimate the number of APIs they have in the organization from 50% to 400%. So, it’s a very, very, very large problem that we see happening. 

Next, I would start doing some significant contract reviews 

It may be worth engaging a company to really understand what your total spend is, to make sure that you understand spending per vendor, and to look for potential to consolidate across the organization. From there, you can start master services agreement (MSA) negotiations and contract negotiations to really drive the price down – particularly with end-points. Many organizations think their spending is anywhere from 40 to 60% of what their actual spend, for things distributed out into the organization. The ability to consolidate that can be a significant cost saving. 

You can also look at vendor consolidation/partner consolidation. You will likely have more vendors than you need. Now is a good time to think about those that are really providing distinguished value back to your organization. They are really helping you think about your business and the business of providing technology as a business and start consolidating to those. That way, first. you can lower the chatter that occurs, but second, you can also again leverage of the power of your wallet, and get a little more value from those relationships. 

Finally, as you go toward the end of the year, I would be thinking about your people

We estimate that people costs are increasing by about 15% in the next year. And so, anyone that you haven’t given a 15% raise to in 2022 and 2023, or is in a recent acquisition where they were paying those proper wages, is likely going to be looking for somewhere else to go, and as we all know, you tend to lose your most valuable people first. So, I’d really be paying attention to that, and looking after them. 

Most major financial organizations have entered a lockdown period where they allow no changes between now and the 1st of next year. A lot of that has to do with the buying that occurs during the holiday season and making sure that there’s zero interruption to that. Well, it’s not going to hurt you to do the same thing and really enter into a period of change/freeze, as well as reflection and relaxation. 

There’s this addiction to this final push to complete things before the end of the year, but honestly, it tends to be arbitrary. You may have to push to complete those projects, but the reality is, now is the time to stop as much change as possible, and free up as many resources to let them start taking vacation in larger numbers. There’s nothing like being able to be the employer that says, “Hey, go spend time with your family, relax”. To also have the family really change their focus and be able to say, “You haven’t been home much in the last few months, but it’s nice to see you, and maybe this employer is good!”

The post Hot Topics For The Mid-Market In 2023 appeared first on Gigaom.

That worked well when the opposition was not sophisticated, most end-user workstations were desktops, the number of remote users was very small, and we had all our servers in a series of data centers that we controlled completely or in part. We were comfortable with our place in the world and the things we built. Of course, we were also asked to do more with less, and this security posture for critical infrastructure was simple and less costly than the alternative.

Starting around the time of Stuxnet, this started to change. Secure access went from a poorly understood, accepted cost and backroom discussion to one being discussed with interest in board rooms and at shareholder meetings. 

Overnight the executive level went from being able to be ignorant of cybersecurity to having to be knowledgeable of the company’s disposition on cyber. Attacks increased, and major news organizations started reporting on ransomware attacks, data breaches, and cyber incidents. Legislation changed to reflect this new world, and more is coming. How do we handle this new world and all of its requirements?

Zero Trust is a change in information security. Zero Trust is a fundamental change in a cybersecurity strategy. Whereas before, we focused on boundary control and built all our security around the idea of inside and outside, now we need to focus on every component and every person potentially being a Trojan Horse. It may look legitimate enough to get through the boundary, but in reality, it could be hosting a threat actor waiting to attack. 

Even better, your applications and infrastructure could be a time bomb waiting to blow, where the code used in those tools is exploited in a “Supply Chain” attack. Where through no fault of the organization, they are vulnerable to attack. 

Zero Trust says – “You are trusted only to take one action, one time, in one place, and the moment that changes, you are no longer trusted and must be validated again, regardless of your location, application, userID, etc.” Zero Trust is exactly what it says, “I do not trust anything, so I validate all the things.”

That is a neat theory, but what does that mean in practice? We need to restrict users to the absolute minimum required access to networks that have a tight series of ACL’s, to applications that can only communicate to those things they must communicate with, to devices segmented to the point they think they are alone on private networks while being dynamic enough to have their sphere of trust changed as the organization evolves, and still enable management of those devices. 

The overall goal is to reduce the “blast radius” any compromise to sensitive data would allow in the organization since it is not a question of “if” but “when” for a cyber attack.

So if my philosophy changes from “I know that and trust it” to “I cannot believe that is what it says it is,” then what can I do? Especially when I consider I did not get a 5x budget to deal with 5x more complexity. I look to the market. Good news! Every security vendor is telling me how they solve Zero Trust with their tool, platform, service, and new shiny thing. So I ask questions. It seems to me they only really solve it according to marketing. Why? 

Because implementing Zero Trust is hard. It is very hard. Complex, it requires change across the organization, not just tools, but the full trifecta of people, process, and technology, and not restricted to my technology team, but the entire organization, not one region, but globally. It is a lot.

All is not lost, though, because Zero Trust isn’t a fixed outcome; it is a philosophy. It is not a tool, an audit, or a process. I cannot buy it, nor can I certify it (no matter what people selling things will say). So that shows hope. Additionally, I always remember the truism; “Perfection is the enemy of Progress,” and I realize I can move the needle.

So I take a pragmatic view of security through the lens of Zero Trust. I don’t aim to do everything all at once. Instead, I look at what I am able to do and where I have existing skills. How is my organization designed? Am I a hub and spoke where I have a core organization with shared services and largely independent business units? 

Maybe I have a mesh where the BU’s are distributed to where we organically integrated and staffed as we went through years of M&A. Maybe we are fully integrated as an organization with one standard for everything. Maybe it is none of those.

I start by considering my capabilities and mapping my current state. Where is my organization on the NIST security framework model? Where do I think I could get with my current staff? Who do I have in my partner organization that can help me? Once I know where I am, I then fork my focus.

One fork is on low-hanging fruit that can be resolved in the short term.  Can I add some firewall rules to better restrict VLAN’s that do not need to communicate? Can I audit user accounts and make sure we are following best practices for organization and permission assignment? Does MFA exist, and can I expand its use or implement it for some critical systems?

My second fork is to develop an ecosystem of talent organized around a security-focused operating model, otherwise known as my long-term plan. DevOps becomes SecDevOps, where security is integrated and first. My partners become more integrated, and I look for, and acquire relationships with new partners that fill my gaps. 

My teams are reorganized to support security by design AND practice. And I develop a training plan that includes the same focus on what we can do today (partner lunch and learns) with long-term strategy (which may be up-skilling my people with certifications).

This is the phase where we begin looking at a tools rationalization project. What do my existing tools not perform as needed in the new Zero Trust world? These will likely need to be replaced in the near term. What tools do I have that work well enough but will need to be replaced at the termination of the contract? What tools do I have that we will retain?

Finally, where do we see the big, hard rocks being placed in our way?  It is a given that our networks will need some redesign and will need to be designed with automation in mind because the rules, ACL’s, and VLAN’s will be far more complex than before, and changes will happen at a far faster pace than before. Automation is the only way this will work. The best part is modern automation is self-documenting.

The wonderful thing about being pragmatic is we get to make positive change, have a long-term goal in mind that we can all align on, and focus on what we can change while developing for the future. All wrapped in a communications layer for executive leadership and an evolving strategy for the board. Eating the elephant one bite at a time.

The post Pragmatic view of Zero Trust appeared first on Gigaom.