Mind the (security) gap: how to scale like a pro with Zoë Rose

 I saw a presentation recently that said: big organizations have the people, the skills and the resources, so tooling isn’t as important. The small companies don’t have the resources or the people, and so the tooling is a lot more important.

If you’re a small organization and you’re trying to keep up with enterprises, you probably have a restricted budget, so the first thing you think of is: what can I get by with for the time being? Many have the best intentions, but they don’t have the proper tooling for the use case that they’re trying to build to.

A common failure is that companies don’t design for growth in mind. They’re giving individual permissions or unique scenarios without documenting it, or even if its actually needed. If that’s documented and it fits with the plan, then it makes sense. But often it’s, “This cheaper tooling fits, so let’s go with that” or “We’ll add that tool later” or “here’s a tooling that’s well known” without doing the proper analysis on if it covers the requirements.

Another big one is, “We hired a third party because it is not our core competency”. I get that, but do they report to you? How do you maintain that they’re doing what they say they’re doing?

Understand what your business is. Security does not secure everything completely — I wouldn’t have a job if it was the case! The reality of security is: securing your environment whilst balancing the ability to get work done. You can ask yourself, what do I need to protect? What are my assets? What are my workflows? What is my inherent risk? What am I trying to protect against? What is my threat map? Understand what your landscape is, and what tooling do you have in place?

Shadow IT is a big problem in so many organizations. Unfortunately, that’s because we’re not identifying our requirements. You may have the shiny tool, but in reality, what is needed? Once you know that, it’s going to be a lot easier and more effective to implement a secure-by-design approach.

The important part is knowing where your responsibility is. I’ve dealt with a lot of situations where the client and their third party were overlapping duties, or worse, they had huge gaps that neither party knew they had the responsibility for. If you’re following best practices and know your responsibilities, then you’re already in a better state than a lot of other companies.

Get things in writing. If your client says, “Access our environment through RDP. Here’s a password that we all share.” You should get in writing that you’ve advised them not to do this and why you’ve advised them not to. It shows you’re going above and beyond. You’re already giving a benefit to having a relationship and building trust. Be proactive.

And yes, sometimes clients will not listen. If something is breached, if a password is stolen, you’ve made that recommendation. You’ve met your responsibility

Looking at what was done wrong is so critical because if you don’t take that view, you’re going to miss things that you can learn from and improve on.

You need a culture where people feel safe to admit when they’ve done something wrong or where they’ve seen bad practices. People can be the strongest asset. Tooling is designed to do certain things, but it does not think consciously. It doesn’t know your job, especially if you’re getting a phishing email from someone you have an existing relationship with. The users, on the other hand, they can make that assessment.

I’m still shocked today at the number of customers that I’ve worked with who didn’t have a risk register. It doesn’t have to be fancy. It could be an Excel document. Knowing your environment, likely risks, this is going to put you in a good place to know how to protect yourself and identify where you have gaps. 

How are you going to recognize an incident if you don’t know what’s going on? The tooling is designed to detect unusual activity, but if everything is unusual, you’ll have an exhausted security operations team.

Also, invest in the right areas. If you’re spending so much money on security that it’s impacting your core competencies, you’re doing it wrong. If you’re spending nothing, you’re also doing it wrong. The business needs to have a relationship with security and IT. But IT and security also need to have a relationship with the business.

From an MSP perspective, a client who is constantly ignoring your advice. If an incident happens, they may even try to blame you. Make sure in your clauses you know exactly where your responsibility is. It takes time, money, effort and resources to investigate a breach. Make sure that that is very well defined.

From an auditing perspective, if it is not documented, it does not exist. If you don’t follow a governance process, if you don’t manage the relationship, review documents and dashboards, then it’s probably not happening.

You need to have a plan. Ask yourself: what is the goal? What is your architecture? What are the things that I need to comply with?

For a parent company with smaller companies, have your plan, know what the requirement to meet is and know what your plan is when you’re buying your company. It could be you don’t ever actually plan to embed them. That’s valid, but they still need to meet the relevant requirements. If you want to embed them, how much work is that going to be? Look at what they have in place.

I’ve had companies being purchased tell me they have had no security incidents in the last 12 months. If you’ve had no security incidents, it doesn’t mean you’re secure—it means you don’t know. To me, that is a massive red flag.If a company tells me they’ve had incidents, resolved them, actively taking learnings from it and implementing tools, that looks a lot more attractive to me because they’ve consciously thought about it and they’re trying to improve. That means they probably know the environment better.

 So many IT projects fail because they didn’t document the requirements. They didn’t talk to the users. If it doesn’t let people get their job done, there’s going to be shadow IT.

Make sure any risks are documented and you’re very clear of what their responsibility is and have it in writing. So if a breach happens because of a poorly designed system or process, and you warned them, you can say you did your job. You need to protect yourself. The client is going to have to take the responsibility.

Look at what your inherent needs are and what makes sense in your environment. But as a general trend, identity is a very important area. Threat actors are trying to do the least amount of work to get the most back, and the way to do that is to take over existing accounts by manipulating the end user.

If you know what’s in your environment, your users and what their usual activity is, you can flag things outside the norm, which is going to be effective in stopping attacks. There are lots of solutions out there that you can go with. Choose what makes sense to you and your existing vendor relationships.