Cyber Essentials, another question "Organisational data"

[GrumbleDook]

Were we not all saying a few months ago that security by obscurity is not security at all?

 

And this is not security by obscurity.

 

This is looking at a risk, looking at the level of risk based on the context and mitigating actions (at this point some folk might add obscurity as a mitigation, but that would not be relevant here) and then seeing where the risk sits within the risk acceptance criteria the organisation has.

 

The assumption that is being made is that there is the same level of risk between staff accounts and children's accounts, and that there are the same levels of risk between secondary and primary children.

This is before we get into the structure and configuration of the organisation's systems ... and how that can vary to a massive degree.

 

Ignoring risks is also a different matter. I don't think anyone is advocating that.

[paulkerton]

And this is not security by obscurity.

It absolutely is security by obscurity. "Well if they don't know our IP address we're fine" is not by any stretch of the imagination working from a position zero trust.

 

The assumption that is being made is that there is the same level of risk between staff accounts and children's accounts, and that there are the same levels of risk between secondary and primary children.

 

The assumption being made here is that the risk isn't internal in the first place, but that's one of the biggest risks you'll have, be it from staff or children. Are you differentiating traffic from staff and students to identify with different IP addresses, so if a staff member logs into a machine on the student system, they're still required to use 2FA?

[dmj]

Does it though? That's my point... Spoofing an IP address isn't exactly difficult.

 

Unless you want the traffic to be bi-directional (which you will in this case), it's not as simple as you're making out unless you already own the target ISP.

[free780]

It absolutely is security by obscurity. "Well if they don't know our IP address we're fine" is not by any stretch of the imagination working from a position zero trust.

 

 

 

The assumption being made here is that the risk isn't internal in the first place, but that's one of the biggest risks you'll have, be it from staff or children. Are you differentiating traffic from staff and students to identify with different IP addresses, so if a staff member logs into a machine on the student system, they're still required to use 2FA?

 

Speaking of AzureAD. You can make a AAD joined device a requirement or MFA. The IP address issue is taken away.

 

Any abuse of accounts will now be on AAD/HADDJ devices. These need protecting with AV etc.

[GrumbleDook]

It absolutely is security by obscurity. "Well if they don't know our IP address we're fine" is not by any stretch of the imagination working from a position zero trust.

 

That is not something I have said, or would ever likely to say. The correct statement would be something like ...

 

"From the present cohort of children that are in the school, what is the likelihood that any one of them would have the skills and knowledge to be able to set up a personal device on our network in such a manner to compromise it, to be able use a school-owned device in a similar manner and what would be the impact of this? What are the mitigating factors in this that are already in play that already work to reduce either the likelihood or the impact?"

 

Security by obscurity is a poor piece of mitigation, but focussing on that is not the be all and end all.

 

The assumption being made here is that the risk isn't internal in the first place, but that's one of the biggest risks you'll have, be it from staff or children. Are you differentiating traffic from staff and students to identify with different IP addresses, so if a staff member logs into a machine on the student system, they're still required to use 2FA?

 

Again, I don't think anyone is downplaying that internal vectors are extremely valid concerns. Again, it is a risk management.

When we talk about zero-trust architecture, I tend to go back to the 10 principles from the 2019 NCSC zero trust architecture design principles.

There is no limit on what provides the authentication, except what you have deemed appropriate for your network based on the other principles. As I keep saying (and will keep on saying), your risk analysis may be different to others. That is not saying you are right or wrong, or other are right or wrong ... just that you have differences.