What does it mean to build in security from the ground up?
(2025/02/02)
- Reference: 1738517168
- News link: https://www.theregister.co.uk/2025/02/02/security_design_choices/
- Source link:
Systems Approach As my Systems Approach co-author Bruce Davie and I think through what it means to apply the systems lens to security, I find that I keep asking myself what it is, exactly, that’s unique about security as a system requirement?
That question takes me back to a time before security became such a mainstream news topic; before security breaches were so common that we’ve become desensitized to the news of another one. Believe it or not, there was a time when Internet security was not on the public’s mind, and the task at hand was to raise awareness of the security risks the internet posed.
This was well after the [1]Morris Worm made it painfully obvious how impactful a security incident could be. That was a wakeup call for the research community ( [2]myself included ), who were at the time the only serious internet users. That experience (and others) eventually led to a concerted effort to educate the public about security. Two personal opportunities in the mid-2000s to get on a soapbox and talk about security come to mind.
The echo on the line was so bad it was hard to keep your wits about you
The first was an invitation to be a guest on [3]Ira Flatow’s Science Friday . I haven’t been able to reconstruct the details — there were other “future of the internet” experts on the show — but I do remember my role was to talk about the risks of security incidents, and how we needed to rethink the internet architecture from the ground up to make it more secure. (This was at a time when [4]PlanetLab , a networking research hub of which I was director, was getting a lot of press coverage as a laboratory for [5]reinventing the internet.)
My only vivid memory of the experience is that I called into [6]the Science Friday show over an ISDN line terminated in a sound recording room at Princeton, and the echo on the line was so bad it was hard to keep your wits about you.
[7]
The second opportunity took place at a Princeton Development Retreat at Pebble Beach. (In university vernacular, “Development” is a fundraising endeavor and, at Princeton, faculty are sometimes invited to talk about their research at events attended by wealthy alumni.) In this particular case, I teamed up with Tom Leighton, an alum and co-founder of Akamai, to talk about internet security.
[8]
[9]
Tom played the bad cop (telling everyone about the security threats exposed by the data Akamai collects) and I played the good cop (Princeton researchers to the rescue, building a more secure internet for the future). We must have made an impression because, shortly afterwards, we were invited to the White House to brief the Deputy National Security Advisor on internet security risks.
Again, my most vivid memory is about the most banal detail – in this case, how small an office the advisor had. I’m also pretty sure we weren’t telling him anything he didn’t already know.
Security as a motivator
What do I take away from these stories? For one, while I believe it is important for innovators to educate and inform the public about the implications of technology they are inventing, it is also clear that we (computer science researchers, the universities that employed us, and the government funding agencies that lobbied for appropriations so they could fund our research) were at least in part using security for its motivational value. There’s nothing quite like fear to get people to act.
That’s definitely one thing that’s unique about security as a systems requirement: Security is something that’s easily understood by the general public. But I wonder whether the “we need to build in security from the ground up” part of the message actually makes sense. It sounds good — and the alternative of “bolting security onto existing systems” was intentionally pejorative – but I’m not sure it’s a meaningful goal.
[10]
One reason to doubt that message — which gets at the heart of the “what’s unique” question — is that we have succeeded in building highly modular security mechanisms that can be reused by any and all applications. Kerberos and TLS are two great examples. The last thing we’d want is for every system or application to have to get the details of complex authentication protocols, key distribution protocols, and so on, right. Pushing for security "from the ground up" ought not to discourage the use of perfectly capable, preexisting modular security mechanisms.
[11]Security is hard because it has to be right all the time? Yeah, like everything else
[12]Security is an architectural issue: Why the principles of zero trust and least privilege matter so much right now
[13]Windows: Insecure by design
[14]Good luck securing 'things' when users assume 'stuff just works'
What security-related issues you have to address on day one? Certainly if you expect a system to be multi-tenant, you have to define the level of isolation you want to maintain between tenants/users, and implement mechanisms that enforce it, from the ground up.
But I don’t consider isolation (or its counterpart, resource sharing) to be a security question, at least not in the ways we talk about security today. Early timesharing operating systems and filesystems were supporting isolation without directly considering potential attack vectors. Isolation was primarily about fair resource allocation and efficient utilization; naming and addressing were critical to enabling resource sharing; and privileged operations were limited to the kernel. Malicious attacks were generally not a “failure mode” under consideration. Design questions about isolation, privilege, and access control were expressed as “positive goals” that could be satisfied.
Today if you were to build a multi-tenant system you’d have to start with the same fundamental design issues — eg, identify the relevant principals and resources and specify who can access what — but then you would employ existing security mechanisms to protect the resulting system from known attacks.
This suggests that knowing about the state of the art in security mechanisms, and how to use them, is what it means to build in security from the ground up. It turns out that this is just one bullet item on a list of a general set of best practices software companies require their developers to follow.
[15]
If you're not familiar with such requirements, [16]take a look at Microsoft’s Security Development Lifecycle (SDL) Practices, which is targeted at app developers who might deploy their services on Azure. I’d wager most software companies have similar, if not more stringent, engineering requirements for their own engineers to follow. I’d also wager the measures each company takes to ensure those rules are followed is highly variable.
The list is as applicable to sound software engineering in general as to security specifically, but the existence of security-focused lists like this suggest to me that security is unique in one way: The strong negative incentive that failure to secure provides. The failure modes are as unlimited as an attacker’s imagination, making security a “negative goal."
Personally, I’ve never found work that primarily involves keeping bad things from happening all that satisfying, but as I learned from my “soapbox” experiences, it is a strong motivator. ®
Larry Peterson and Bruce Davie are the authors behind [17]Computer Networks: A Systems Approach and the related [18]Systems Approach series of books. All their content is open source and available for free on [19]GitHub . You can find them on [20]Mastodon , their newsletter [21]right here , and past The Register columns [22]here .
Get our [23]Tech Resources
[1] https://en.wikipedia.org/wiki/Morris_worm
[2] https://www.theregister.com/2022/02/09/section_8_unix_user_manual/
[3] https://www.sciencefriday.com/
[4] https://planetlab.cs.princeton.edu/history.html
[5] https://planetlab.cs.princeton.edu/impact.html
[6] https://www.npr.org/transcripts/5434633?storyId=5434633?storyId=5434633
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cso&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z5_5DYp0bT2mC0zlRIcXVAAAAEQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cso&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z5_5DYp0bT2mC0zlRIcXVAAAAEQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cso&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z5_5DYp0bT2mC0zlRIcXVAAAAEQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cso&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z5_5DYp0bT2mC0zlRIcXVAAAAEQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[11] https://www.theregister.com/2024/02/25/security_not_different/
[12] https://www.theregister.com/2021/05/27/security_architecture/
[13] https://www.theregister.com/2024/06/28/windows_insecure_by_design/
[14] https://www.theregister.com/2016/10/27/good_luck_securing_things_when_users_assume_stuff_just_works/
[15] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cso&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z5_5DYp0bT2mC0zlRIcXVAAAAEQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[16] https://www.microsoft.com/en-us/securityengineering/sdl/practices?oneroute=true
[17] https://book.systemsapproach.org/
[18] https://www.systemsapproach.org/
[19] https://github.com/SystemsApproach
[20] https://discuss.systems/@SystemsAppr
[21] https://systemsapproach.org/newsletter/
[22] https://www.theregister.com/Tag/Systems%20Approach
[23] https://whitepapers.theregister.com/
That question takes me back to a time before security became such a mainstream news topic; before security breaches were so common that we’ve become desensitized to the news of another one. Believe it or not, there was a time when Internet security was not on the public’s mind, and the task at hand was to raise awareness of the security risks the internet posed.
This was well after the [1]Morris Worm made it painfully obvious how impactful a security incident could be. That was a wakeup call for the research community ( [2]myself included ), who were at the time the only serious internet users. That experience (and others) eventually led to a concerted effort to educate the public about security. Two personal opportunities in the mid-2000s to get on a soapbox and talk about security come to mind.
The echo on the line was so bad it was hard to keep your wits about you
The first was an invitation to be a guest on [3]Ira Flatow’s Science Friday . I haven’t been able to reconstruct the details — there were other “future of the internet” experts on the show — but I do remember my role was to talk about the risks of security incidents, and how we needed to rethink the internet architecture from the ground up to make it more secure. (This was at a time when [4]PlanetLab , a networking research hub of which I was director, was getting a lot of press coverage as a laboratory for [5]reinventing the internet.)
My only vivid memory of the experience is that I called into [6]the Science Friday show over an ISDN line terminated in a sound recording room at Princeton, and the echo on the line was so bad it was hard to keep your wits about you.
[7]
The second opportunity took place at a Princeton Development Retreat at Pebble Beach. (In university vernacular, “Development” is a fundraising endeavor and, at Princeton, faculty are sometimes invited to talk about their research at events attended by wealthy alumni.) In this particular case, I teamed up with Tom Leighton, an alum and co-founder of Akamai, to talk about internet security.
[8]
[9]
Tom played the bad cop (telling everyone about the security threats exposed by the data Akamai collects) and I played the good cop (Princeton researchers to the rescue, building a more secure internet for the future). We must have made an impression because, shortly afterwards, we were invited to the White House to brief the Deputy National Security Advisor on internet security risks.
Again, my most vivid memory is about the most banal detail – in this case, how small an office the advisor had. I’m also pretty sure we weren’t telling him anything he didn’t already know.
Security as a motivator
What do I take away from these stories? For one, while I believe it is important for innovators to educate and inform the public about the implications of technology they are inventing, it is also clear that we (computer science researchers, the universities that employed us, and the government funding agencies that lobbied for appropriations so they could fund our research) were at least in part using security for its motivational value. There’s nothing quite like fear to get people to act.
That’s definitely one thing that’s unique about security as a systems requirement: Security is something that’s easily understood by the general public. But I wonder whether the “we need to build in security from the ground up” part of the message actually makes sense. It sounds good — and the alternative of “bolting security onto existing systems” was intentionally pejorative – but I’m not sure it’s a meaningful goal.
[10]
One reason to doubt that message — which gets at the heart of the “what’s unique” question — is that we have succeeded in building highly modular security mechanisms that can be reused by any and all applications. Kerberos and TLS are two great examples. The last thing we’d want is for every system or application to have to get the details of complex authentication protocols, key distribution protocols, and so on, right. Pushing for security "from the ground up" ought not to discourage the use of perfectly capable, preexisting modular security mechanisms.
[11]Security is hard because it has to be right all the time? Yeah, like everything else
[12]Security is an architectural issue: Why the principles of zero trust and least privilege matter so much right now
[13]Windows: Insecure by design
[14]Good luck securing 'things' when users assume 'stuff just works'
What security-related issues you have to address on day one? Certainly if you expect a system to be multi-tenant, you have to define the level of isolation you want to maintain between tenants/users, and implement mechanisms that enforce it, from the ground up.
But I don’t consider isolation (or its counterpart, resource sharing) to be a security question, at least not in the ways we talk about security today. Early timesharing operating systems and filesystems were supporting isolation without directly considering potential attack vectors. Isolation was primarily about fair resource allocation and efficient utilization; naming and addressing were critical to enabling resource sharing; and privileged operations were limited to the kernel. Malicious attacks were generally not a “failure mode” under consideration. Design questions about isolation, privilege, and access control were expressed as “positive goals” that could be satisfied.
Today if you were to build a multi-tenant system you’d have to start with the same fundamental design issues — eg, identify the relevant principals and resources and specify who can access what — but then you would employ existing security mechanisms to protect the resulting system from known attacks.
This suggests that knowing about the state of the art in security mechanisms, and how to use them, is what it means to build in security from the ground up. It turns out that this is just one bullet item on a list of a general set of best practices software companies require their developers to follow.
[15]
If you're not familiar with such requirements, [16]take a look at Microsoft’s Security Development Lifecycle (SDL) Practices, which is targeted at app developers who might deploy their services on Azure. I’d wager most software companies have similar, if not more stringent, engineering requirements for their own engineers to follow. I’d also wager the measures each company takes to ensure those rules are followed is highly variable.
The list is as applicable to sound software engineering in general as to security specifically, but the existence of security-focused lists like this suggest to me that security is unique in one way: The strong negative incentive that failure to secure provides. The failure modes are as unlimited as an attacker’s imagination, making security a “negative goal."
Personally, I’ve never found work that primarily involves keeping bad things from happening all that satisfying, but as I learned from my “soapbox” experiences, it is a strong motivator. ®
Larry Peterson and Bruce Davie are the authors behind [17]Computer Networks: A Systems Approach and the related [18]Systems Approach series of books. All their content is open source and available for free on [19]GitHub . You can find them on [20]Mastodon , their newsletter [21]right here , and past The Register columns [22]here .
Get our [23]Tech Resources
[1] https://en.wikipedia.org/wiki/Morris_worm
[2] https://www.theregister.com/2022/02/09/section_8_unix_user_manual/
[3] https://www.sciencefriday.com/
[4] https://planetlab.cs.princeton.edu/history.html
[5] https://planetlab.cs.princeton.edu/impact.html
[6] https://www.npr.org/transcripts/5434633?storyId=5434633?storyId=5434633
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cso&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z5_5DYp0bT2mC0zlRIcXVAAAAEQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cso&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z5_5DYp0bT2mC0zlRIcXVAAAAEQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cso&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z5_5DYp0bT2mC0zlRIcXVAAAAEQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cso&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z5_5DYp0bT2mC0zlRIcXVAAAAEQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[11] https://www.theregister.com/2024/02/25/security_not_different/
[12] https://www.theregister.com/2021/05/27/security_architecture/
[13] https://www.theregister.com/2024/06/28/windows_insecure_by_design/
[14] https://www.theregister.com/2016/10/27/good_luck_securing_things_when_users_assume_stuff_just_works/
[15] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cso&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z5_5DYp0bT2mC0zlRIcXVAAAAEQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[16] https://www.microsoft.com/en-us/securityengineering/sdl/practices?oneroute=true
[17] https://book.systemsapproach.org/
[18] https://www.systemsapproach.org/
[19] https://github.com/SystemsApproach
[20] https://discuss.systems/@SystemsAppr
[21] https://systemsapproach.org/newsletter/
[22] https://www.theregister.com/Tag/Systems%20Approach
[23] https://whitepapers.theregister.com/
Which way round
Will Godfrey
Do you specify what isn't permitted,or what is permitted. If it's the former you risk missing new attack types, but if it's the latter use get frustrated with the restrictions and verifying new stuff can become complicated.
Re: Which way round
Giles C
On the firewall side the general principle is allow only what is stated.
Which frustrates users but does mean we keep it under control, but then management don’t want to run ssl decryption in line so the firewall has no choice but to let the traffic through without being able to inspect the payload so it is secure or not.
We know the endpoints are talking but that is it… whereas unencrypted traffic can go thorough the analytics engines built into the platform.
Start by being aware of what the system is *for*
John Smith 19
Does it handle money?
Does it handle personal information?
Does it control vital infrastructure (at least vital to someone).
Does it have national security information?
Does it control a weapon(s)?
That starts you on an idea of what sort of bad actors you will be facing.
And never, ever trust user input, even if it comes from a frontend app you wrote, but with data sent through the interwebs IE everything.
"Security" - It Depends On Exactly What Security.........
Anonymous Coward
So...multi-tenant.....security of one tenant from another.
So...email, Signal, Telegram......security of ANY user against who knows which attacker.
So...cloud user....security against the cloud OWNER......
So...cloud user....security against anyone else......
So...copyright owner....against anyone at all....not least multiple "big data" aggregators.....
So...medical services user....against anyone at all....not least multiple "big data" aggregators.....
...and so on......the use of the word "security" is itself a weasel word....used indiscriminately..........
.....to worry people like me who know almost nothing about technology in 2025!!!!
So....please explain!!
What it is, exactly, that’s unique about security as a system requirement?
It's a negative requirement.
A secure system is basically a system that is incapable of doing things that are not specified.
Requirements to any system define a limited list on what the system shall do after implementation.
Execute functions, show values, read inputs, wrtite outputs, etc.
Checking correctness and completeness is easy: Just test if every defined function works, if every defined input creates the specified output.
Security requirements are in contrast an nearly indefinite, negative list of things a system must NOT do, e.g. everything that is not in the requirements.
Like multiple types of crashes, multiple ways of letting external calls modify internal states without authorization, misunderstand authorization of a request, do funny things on garbeled inputs, garbling outputs, etc.
Each of those things a system must not do in turn has multiple potential causes, that are pretty specific to program, context and architecture.
So completely checking security is a basically indefinite task, as is requires an indefinite amount of different inputs/actions to be executed and verified to not result in a failure.
Security _is_ hard.