Security Architecture Anti-Patterns
ncsc.gov.uk
ncsc.gov.uk
The real-world practice of security is in large part the deployment of risky systems with mitigations in place for the likely attacks that will target them. So, for instance, getting everyone to talk to the admin console on a purpose-built Chromebook with no Internet access is probably not a realistic option, but getting every system with admin console access MDM'd and requiring access to admin consoles to route through an IdP like Okta to enforce 2FA is much more realistic, and thus likely to happen.
The patterns in here that aren't unrealistic are pretty banal. I don't doubt that UK NCSC sees systems designed to be unpatchable, but modern engineering norms (Docker, blue/green, staging/cert environments) --- norms that have really nothing to do with security and are common to pretty much every serious engineering shop --- address that directly anyways.
Other patterns don't really make sense; for instance: you should design to make your systems patchable (sure, that's again a basic engineering requirement anyways), but also make sure your dev and staging environments aren't continuously available. Why? Those are conflicting requirements.
This is more a list of anecdotes that are definitely bad. But they’re not representative of the kinds of common mistakes I would call out.
The "browse-up" scenario is extremely common because engineers/administrators usually prefer to remote directly onto the systems their working on from their main machine rather than endure the inconvenience of needing to securely connect to another host first. Many of these admins/engineers would think it's inconceivable for their machines to be vulnerable but have no issues downloading dev tools, libraries and dependencies onto their machines from third party & untrusted sources (e.g. Github, NPM, etc).
'Docker, blue/green, staging/cert environments" - believe it or not, these are seen as emerging trends in many orgs rather than the norm as you suggest here.
And regarding designing systems to be patchable, you say: "sure, that's again a basic engineering requirement anyways", but again I'd counter that I've come across many systems that haven't been patched in months or years because it's deemed too hard. Another similar issue I've come across is where an org's DR processes have not been properly tested because it's too hard to failover without causing significant disruption. Both can easily be designed for early on, but for legacy systems that were implemented without this foresight it still remains an issue.
> There are many ways in which you can build a browse-down approach. You could use a virtual machine on the administrative device to perform any activities on less trusted systems.
The point is to tailor your risk to the systems your accessing. You should interact with less trusted content in more secure ways if you're also interesting with high security systems.
So if you're using firejail/bubble wrap to consume less trusted content (web, email, videos, etc.) and selinux/apparmor; I think your system would match their description of browse-down, for most low to mid security systems. For high security maybe Qubes/VMs. Then highest security you start thinking about multiple machines with kvm switches.
For the first one, I would say you could make admins use "clear Chromebooks" but probably no one is going to pay for that.
For other banal ones, I would say it is good to remind people about "management bypasses" are not good idea.
This is how e.g. chip fabs and chemical plants get such loses on power outages. A power plant might be on order of single second of sustain.
The solution there is to actually make the full scale redundancy and compartmentalization or accept the losses.
Most of the time we're not dealing with that.
Everything I’ve seen in ISO security standards, for example, is written at an abstract theoretical level about the design of security bureaucracy rather than the design of actual systems.
One bone to pick: basically all tech companies expect you to be oncall for your services via your laptop. They’re not paying anybody to sit in the office overnight, and commuting in when you get paged with seriously delay mitigation. Is “browsing down” even possible under those circumstances?
Not a security expert, but based on their explanation of "browsing down," I think it's possible if the laptop is sufficiently locked-down. The issue isn't fundamentally with the management device being remote, it's being less-trusted. In the limit case, you could have separate management-only laptops that get passed around to the on-duty employee.
Something like Qubes OS (or maybe manually using containers or virtual machines) could be an option. Running snaps and flatpaks also ensures some level of sandboxing if I'm not mistaken. Using a separate user for riskier activities is also worth thinking about.
I think it's also true that all OSes are moving towards more sandboxing by default (permission to read files, permission to start at runtime, admin access, etc.) so it's less of a risk than it used to be.
Ideally.
How many people are posting here from their work laptops? And how many have SSH access to at least one "secure" system?
Granted, HN is unlikely to be a threat, but other sources may be. There has been progress in sandboxing, but dev machines are specially vulnerable, as in many cases you need people to be admin on them to do their jobs effectively.
For number 1, administering a Windows Active Directory domain controller from a desktop that is also used to browse the public Internet and check email.
For number 6, networking groups use this a lot as the reason to not patch routers.
The reason it ends up focusing on the bureaucracy is because they hope if you can get the bureaucratic part right, the organization can have the relevant expertise in house to make informed decisions about risk, the minimization and mitigation of which is really the goal of the security function.
From TFA:
There are many ways in which you can build a browse-down approach. You could use a virtual machine on the administrative device to perform any activities on less trusted systems. Or you could browse-down to a remote machine over a remote desktop or shell protocol. The idea is that if the dirty (less trusted) environment gets compromised, then it’s not ‘underneath’ the clean environment in the processing stack, and the malware operator would have their work cut out to get access to your clean environment.
Seems like it could be done by having a mobile workstation that doesn't read email or browse the web, just acts as a secure 'satellite' administration device that does little more than VPN back into the administrative network. From there, you jump off to a terminal server if you need to browse or email.
The termination of that admin VPN would probably need to be a distinct endpoint from the general VPN access concentration, and have additional security/authentication measures in place.
That potentially conflicts with IR35 for contractors who would then not be supplying their own equipment.
I've also seen it result in a contractors *nix laptop being swapped out for a Windows laptop (built by a junior employee) with mandated "phone home" software installed. Personal biases persuade me that this wasn't necessarily an improvement in the security of the system.
I should say, I'm generally a fan of NCSC advice and I think it's great they're putting their thoughts out there.
The one I found most surprising was number four. If using PaaS is better practice, then I certainly won't feel lazy anymore for not wanting to deal with the administrative overhead of IaaS (or kubernetes, but that's a different beast entirely, one I try to avoid by using nomad). This will help my impostor syndrome, though calling it that is probably presumptuous on my part.
That aside, why is this site using react to the point they need JavaScript enabled for it to run? What could a site such as this possibly need all that interactivity for? Also why is what seems to be the entire css embedded on the head? That's just weird.
It didn't use this as an example, but good heavens how it is that I still have to understand VPC and NAT to use half of the cloud?
10./192. was never a security measure; it was a IPv4 rationing scheme is that IPv6 made obsolete.
AWS made a big deal of the fact that Lambda functions can now be launched in a VPC in less than 15s.
Why are people doing that at all????
Because of bearded network admins that setup their on-prem network in the cloud.
Now networking in the cloud is so complicated, people are turning to FaaS because has a better chance of skipping the morass.
---
P.S. Don't get security groups confused with NAT. AWS had security groups long before its VPC service was even a thing.
Almost all software (OS's, browsers, databases, load balancers, etc.) supports IPv6.
Some third-party services don't. But that's usually irrelevant to my point. For example, RDS allocates public IPv4 address at no extra cost. In any case, my point is that cloud providers are unwisely shoehorning NAT into everything; citing AWS as a contributing factor just reinforces that.
---
There's no longer any need for local IPs, except so that we can still design 90s-style networks.g
From a security standpoint: because it dramatically improves your security posture. Defense-in-depth is a real thing, and people who care about security use it (the people who pay big bucks).
Nah.
I would maybe question whether an article that can be perfectly embedded in a static PDF without any changes or downgrades really needs an entire React stack and a Service Worker for the browser, but :shrug:. Every org is free to make their own engineering choices.
It does seem to be a pretty good list, so worth taking a look at.
General best practices I can think of, in broad organization level strokes:
1. Make sure security is implemented at the dev ops layer through practices such as logged just-in-time access to production systems, secret vaults for service keys and certificates, airgapped machines for handling secret keys, etc.
2. Make sure security best practices are implemented by default into your API's (CORS, TLS 1.3, whitelist based firewalls between services that shouldn't need to talk to each other, etc.) and make it transparent to the API caller, at least when it's your own services talking to your own services.
3. Make security an element of design and code reviews. Square, for example, did this by having subject matter experts advise teams on security design when projects were still in the ideation/design phase.
Ultimately, security costs a non-trivial amount of time, and it requires training your developers to be able to reason about security.