Schneier on Security

Nick P • April 9, 2014 3:00 PM

@ Anura

“Now I’m thinking maybe I should learn Ada, port it to that, and make C and C++ wrappers for it – which my research tells me is possible.”

That’s what AdaCore did for their Ada Web Server. Except they used OpenSSL. 🙁

Also consider using MatrixSSL. It has excellent properties far as complexity and portability go. You can do it GPL or commercial license. If it’s GPL program, I’d put Ada wrappers around that joker as a start. Then, piece by piece, implement a full SSL library in Ada with little unsafe code as possible, all checks turned on, and only safe defaults allowed (i.e. no NSA backdoor ‘features’). Could gradually reimplement core functions in SPARK, too. See the Skein in SPARK paper for tips on doing it fast.

Bootstrap the crypto part with something like Botan or NaCl. Maybe use an internal security kernel approach like Guttman’s cryptlib. The use of Ada or SPARK would make an assured pipeline approach work better than C/C++. Many possibilities for speeding development or improving security. Good luck.

Nick P • April 9, 2014 6:14 PM

@ DB, NotNickP

Languages are just abstractions over machine language. They all get converted into it. Safety/security features can be included at the high level language layer, the translation layer, or machine code itself. Without ability to change ISA, people tend to go with the first two. So, a language wanting extra safety might bounds check every array, be careful with stack manipulation, take measures for control flow integrity, etc. The tools handle that for the developer. Hence, for those trouble areas, the language is safer or more secure than the language that ignores such trouble areas.

Hence, I think I’m justified in recommending security-critical code be written in a language that prevents or reduces common classes of attack. And it doesn’t necessarily need a VM, either. That comes from the Java, Smalltalk, etc mindset. It might use just careful code generation (eg TAL), extra instructions for certain checks (eg Ada), a safer structuring (eg CFI), a safer interface (eg HLayer), or even a VM/interpreter (eg VLISP). Or a combination of above. The mechanisms vary.

Point is you can use a language that helps safely run your code or one that reliably helps the enemies run their code. Two of you seem to prefer the latter. Feel free to continue writing mission- or security-critical code in C/C++ while checking every function for potential code injections. Even worse, in unsafe languages you have to worry the most at the more common constructs: buffers, strings, etc. (Anyone else ever notice that?) My approach would have you worry less or not at all when doing common things through inherent safety of how language/compiler handle them.

Note: Empirical studies of C++ vs Ada done by defense/aviation industry a long time ago showed most Ada code has significantly fewer bugs while being easier to read. A recent report from Coverity put Python, also a safe[r] language, at a defect rate of 0.05 per 1k of code… one of lowest in industry. So, hard data backs my claim about better language design reducing defects and, hence, vulnerabilities.

Nick P • April 10, 2014 12:19 AM

@ Don

It’s funny you cite System/360 for your “cost too much” claim as IBM spent around $5bil developing it. Only project that decade that cost more and with similar number of people was getting to the moon. If anything, they put nearly everything on the line to make it, got plenty adoption, and enjoyed profitable lock-in for half a century as a result. Quite the success story.

Nick P • April 10, 2014 11:59 AM

@ All re Password Handling

No new or guesswork constructions. This is INFOSEC. We just use what’s been proven in practice. OWASP has a nice cheat sheet on how to properly handle passwords. Use it intead of whatever clever idea you have unless you’re a security engineer or cryptographer.

@ BadMemory

“Somewhere in the documents about the NSA’s ability to break encrypted internet traffic this ability was called “fragile”. Maybe because it was based on a bug introduced to open source code?”

Interesting thought. It could be. It might also be ‘fragile’ in the sense that they weakened protocols or users did plenty plaintext assuming no harm. They’d be concerned trends could shift against them if people’s perception of risk of these things changed.

@ Uhu

“We are talking about a bug in OpenSSL, and as a solution you propose to use a product that uses OpenSSL? :-)”

I saw that too lol. I thought “This is so ridiculous I’m not even posting a critique of it.” Theo de Raadt burning OpenSSL team was the highlight of my day so far, though.

@ Quirk

“The bright sparks working on OpenSSL had customised the memory allocator to “improve performance”, and it was these customisations to the memory allocator that caused the trouble. It would also be possible to do custom memory allocation in managed code land, and that they felt they had to hack memory allocation to improve performance strongly suggests that anything that they would have been doing in managed code would not have been any safer. ”

People writing in more safety-centered systems languages rarely do anything like that. So, it’s already more likely that it wouldn’t happen. That said, these people tried to cheat as you pointed out so this particular development team might shoot themselves in the foot in a safe language. But, it’s kind of a fake argument as you say “But, if they bypass the safety features with bad coding the safety features don’t help.” No kidding. They could also put their private key on twitter. But when do we judge a safety/security tool by how its more foolish users apply it?

“The real killer was that they were using unsanitised user input to work out what should be given back. ”

A good point. My rules of secure development say look at all input coming into the application and check it. It’s a pain that adds a lot of extra code to the app logic. Most just don’t want to do it. Far as tools, there are cutting-edge systems that tag all data with a provenance bit and impose restrictions on externally-generated data. Then, a bit more practical, there are software libraries & frameworks that do input validation of certain types. However, if it’s not well-understood and common case, I think it will always be up to the developer to just think about their application, identify potential input problems, and fix them.

Systems enforcing POLA, strong modularity, memory compartmentalization, etc. can also help here in containing damage. For instance, I had one design for secure web server that broke it up into separate address spaces on a microkernel. The SSL & HTTP connection mgmt processes were both isolated. Message passing was architecture and web server components could only talk to message router. They ask “may I,” where router then checks source, destination, and size against security policy before moving message itself. Compromising any given component only allows you to send or receive messages authorized to flow through that component. So, a memory attack on OpenSSL would have trapped to the microkernel, which would send it to a process that handles this stuff. The process would log the error, optionally save entire execution state of SSL partition, notify admin, and temporarily disable web interface. Memory attack merely becomes a loss of availability that also tells me where the 0-day was. The power of sound, security architecture. 😉

Nick P • April 10, 2014 12:46 PM

@ Sad Clown

This page covers everything you need to know about its intentions and benefits:

http://www.adaic.org/advantages/

Nick P • April 10, 2014 2:12 PM

@ Benni

“Retroshare has enough layers of security that the even the nsa will have to work really hard if they want to get in there.”

And it’s written in a risky language using shoddy libraries on platforms NSA has 0-days and automated attack systems for. I’m sure that this combination will be “really hard” for NSA to penetrate. 😉

QED

Nick P • April 10, 2014 9:50 PM

@ Benni

Thanks for the NSA slide. It’s good to know they were still having trouble in 2012. I’d like to have more data on what they can do. Right now, we only have that slide set and posts like this. The part that jumps out most is Runa (worked on tor) says: “Global dragnet surveillance was never part of the threat model…” And that’s what NSA is building. Hence, the protocol will only get weaker over time barring major breakthroughs in anonymity tech.

Someone also posted here a while back a discussion about a certain weakness and a mailing list conversation. In short, the Tor person said the system would be broken against an adversary who could see about all network traffic. Similar to what Runa said. However, these problems just mean Tor isn’t perfect against a global TLA and that it’s clearly still an obstacle to them. If anything, it justifies it’s use for private web traffic as anything hard for NSA is probably really hard for everyone else. Just know that there’s always a risk re NSA and low tech tradecraft is still the safest if it’s something they’d really get you for. And there’s more ways than ever of encoding/hiding data in ordinary objects mailed to or dropped off at uninteresting places. 😉

Just got an idea…

Remember the map about their exploitation systems? We also have maps of Internet backbone and geographical lists of Tor nodes. There might be a security benefit to creating a whitelist of nodes that mostly in areas they have minimal coverage of. (Or at least did at time of presentation.) That would create gaps in what they see. Then, the threat model goes from global dragnet surveillance to a dragnet surveillance in certain spots. Might help on top of the security Tor already provides.

The other aspect is browsers and apps. Most successful attacks NSA does that I’m aware of are endpoint attacks. They use them to strip Tor’s privacy away. The more effort that can be put into containing attacks on them, the better. Efforts to port browsers such as Quark and OP2 to Tor, with necessary improvements, could go a long way. More modifications to common protocols & network apps to reduce leaks as well. One shortcut, already done by hobbyists, is a hardened device that does nothing but shove all traffic through Tor. I say it needs to go a step further and be a ground-up secure router with a Tor proxy built into it. One of the various clean slate secure hardware-software architectures would be ideal for this.

Back to Retroshare.

“when they say Tor stinks, then so does Retroshare, since both programs are using very similar mechanisms and techniques.”

All the points in favor of Tor do not apply to them unless they use Tor itself. (Idk there.) This is true for about any security claim or evaluation as it has built in assumptions, design, implementation, etc that collectively make the claim true or false. Tor is designed/coded by experts working full-time, enhanced/supported by many others, and constantly reviewed by amateurs and pro’s alike for vulnerabilities. That’s why it’s giving NSA headaches. If Retroshare reuses their codebase, then maybe about the same. Otherwise, they’re doing A Good Thing by obfuscating their traffic & aiming for privacy throughout, but with unknown level of security until it’s thoroughly reviewed by experts.

And if NSA goes after it, they’re certainly going to use experts. Many crypto and anonymity schemes were broken easily once qualified people looked at them. And anonymity is much harder to do right than regular encryption. The program, as I pointed out, also uses the kind of platforms and code that we have precedents of NSA subverting. If it’s safe right now, it’s probably just because most people don’t use it. (see Mac OS X) However, if NSA isn’t in your threat model, then it might be a decent alternative to similar programs as it’s always better to choose those that put effort into security/privacy over those that don’t. The less opponents can vacuum up, the better. That much we agree on for sure.

“and it seems that they have much more problems than retroshare because of this bug.”

Wouldn’t surprise me. They’re also the group that used 1,024-bit ephemeral keys against organizations that spend millions on custom key-cracking machines. (rolls eyes) Nothing shocks me in INFOSEC anymore… Well, maybe if they ported it to DOS. (Googles.) Ok, no DOS version. World is still sane. Kind of.

Nick P • April 11, 2014 4:53 PM

@ Quirk

Main language I’m referring to is Ada. Its basic static checks would’ve caught this. It’s also anything but slow and widely used in safety-critical industries. Others that still have tool support with good performance and some safety enhancements: Pascal (Lazuarus), Modula-2/3 (used still in Europe), PL/I/S (mainframe OS & partners), Typed Assembler, C-like languages (eg Cyclone), and recently people are saying Go too.

Btw, your distinction between “system” and “application” languages is quite artificial. There’s OS’ s written in Java, C#, Haskell, LISP, etc. They’re far from ideal for that but certain structuring and compilation choices mean it can be done. Although I wouldn’t recommend them for it, it just goes to show the system vs app concept mainly depends on how you use them.

I honestly couldn’t even see why you mentioned bloated Java and .NET as, like you said, language under consideration must be fast and low level. That you keep referring to “managed code” while implying it’s slow makes me think they’re your only experience with it. Languages on my list, real systems languages, can be made to give you as much or as little protection as you like. You can, for instance, code an algoritm in SPARK Ada, prove no memory violations exist, and then deploy a “zero runtime” version of that code. Or you can deploy a runtime. Or you can do dynamic checks automatically inserted. Such is why the Mondex CA was written in Ada.

Which brings me to your claim about people working around the safety system in dumb ways for extra raw speed. Yeah, even a safe language usually has a FFI or assembler support so sure they can. But that’s not “using” a safe language: that’s abusing it. Idiots can ruin any good safety net. Doesn’t make the safety net a bad idea or negate its claimed benefits. It just means don’t use libraries from people that do dumb shit in their code, esp if it’s not memory safe. That simple. 😉

Nick P • April 11, 2014 10:02 PM

@ Anura

Great comment. From the problems to tradeoffs, well-presented in general. Btw, to support your point:

A type-safe, TPM-backed TLS implementation in Java
http://www.cs.cmu.edu/~mmaass/tpm_tls/report.html

This prototype uses safe Java code for TLS and the Flicker secure execution scheme that I posted here a while back. We’ve basically proposed using a safer, still efficient, systems language to handle protocol engine. This one is a much higher-overhead option that uses a JVM and a TPM for each operation. Yet, even with all that TPM interaction, the total overhead for initialization is about 3 seconds. They note that’s a problem as it’s noticeable to the user. Yet, the TPM takes up 1-2 seconds of it and Flicker basically freezes the system in time as a side-effect of its operation. The actual encryption and protocol handling seem to happen fast.

The report doesn’t justify mass adoption of Java+TPM+TLS. However, noting similarities and specific performance numbers, I think this report does justify believing that SSL can be coded on a safer or even totally managed language with acceptable performance for users. I’m trying to find examples of SSL in type and/or memory safe code with benchmarks but this report was hopeful at least.

Nick P • April 11, 2014 11:11 PM

I looked up some papers I posted here a while back on statically checked, network apps by Madhavapeddy. His 2006 dissertation set the stage for this 2010 technical report. The guy stay doing good, useful work in INFOSEC. He uses his Ocaml-based protocol development system to develop SSH and DNS systems. The SSH system performed at over 10MBps throughput on a system where OpenSSH did about 20-30. He also noted the crypto library he had to use was 75% slower than what OpenSSH used, which was hand-optimized assembler. So, they had a very high level language with crappy crypto library still getting 10MBps is pretty good. The DNS result was even cooler because Ocaml DNS actually outperformed BIND while also using less code & more safety features. If you can do fast OpenSSH, you can do fast OpenSSL. If you can do fast and safe DNS, then… then you should be using a safe and fast DNS server too, damnit! 😉

Btw, I did find pure implementations of crypto and SSL in Java. They were all late 90’s to early 2000’s commercial and academic. Mostly gone. (shrugs) SSH on Ocaml tells me we could do SSL on Ada, GCJ, etc pretty easy. If performance were a worry, I’d do the following:

1. Use a dedicated core or chip for the SSL processing.
2. Use an event-queue architecture.
3. Ensure SSL function isn’t called until data is in memory.
4. Ensure SSL process’s code and data fit into cache.

The result should be a SSL function with high utilization and efficiency. This should offset some of the burden of safety checks, which is already small for most of them. This is also compatible with MILS architecture I used to promote, meaning SSL engine memory & private key could be isolated at (currently) EAL6+ assurance. Formal analysis of protocol or implementation proving certain properties about data or memory access might also allow checks to be turned off in performance critical areas. (Common trick in SPARK crowd.) Another possibility I’ve seen in the literature is hybrid checks: things easy to statically check are done at compile-time, with the compiler using that information to wisely insert dynamic checks for the rest. Still a catch all problems approach, but with less overhead.

Dissertation quote maybe relevant to SSL bug:

“In Chapter 4 of his PhD thesis [131], Hayden discusses the impact of using OCaml
and notes that reducing memory allocation is a key concern. He also reports that using the
C interface led to hard-to-track bugs, confirming our approach of attempting to attain high
performance without resorting to using foreign-function bindings.”

The code worked fine until they escaped their safety net and relied on C allocation mechanisms. Then, all sorts of weird crap starts happening. Good argument for one instead of the other.

Nick P • April 12, 2014 8:33 AM

@ yesme

What you’re describing is a form of “assured pipelines.” That security model says decompose app into communicating components (typical), then enforce a specific information flow between those components. Highly secure platforms such as LOCK supported this structure. A form of it can be done in SELinux, as it’s a LOCK decendent. Only actual crypto library I know that does this is cryptlib. It has an internal security kernel that ensures each function properly uses other functions. This doesn’t stop, say, a memory attack but does allow one to ensure proper use of the crypto primitives.

Main problem I have with your version is that the command processor is in the TCB. The same thing would be nice if it only happens with simple IPC and input validation. This is essentially what I did with MILS architecture I referenced as separation kernel IPC is fast. They decompose the applications into functions in their own address spaces communicating with kernel IPC per a communications policy.

Nick P • April 12, 2014 8:59 PM

@ sshdoor

I’ve posted on Parasail before. It’s a very nice language in my opinion. It has a good combination of productivity, performance, and safety. This is unsurprising in that the company backing it is a top Ada vendor. 😉 It’s just too new for production use.

Best thing to do with Parasail is this:

1. Identify its internal model for implementing the parallel constructions safely and efficiently.
2. Identify a safe, production-grade language to use for your project.
3. Implement & test the parallel algorithm in Parasail with stub functions.
4. Have a tool automatically translate that, via the model, into code in the safe language.

So, now you have the benefits of Parasail, while keeping a solid language. This is the same kind of thing I’ve done for many tools, languages, environments, etc. Writing C++ in BASIC and/or LISP (with code generator) for automating boilerplate, safety-checks, and more was one of my original uses for such a technique.

List of concurrent and parallel programming languages
http://en.wikipedia.org/wiki/List_of_concurrent_and_parallel_programming_languages

(Just a bonus in case someone didn’t know about this index.)

NIck P • April 17, 2014 6:22 PM

@ Mbck

It’s a bounds-checking error. Wikipedia article lists these languages as supporting it: “Mainstream languages that enforce run time checking include Ada, C#, Haskell, Java, JavaScript, Lisp, PHP, Python, Ruby, and Visual Basic. The D and OCaml languages have run time bounds checking that is enabled or disabled with a compiler switch. C# also supports unsafe regions: sections of code that (among other things) temporarily suspend bounds checking to raise efficiency.”

Ada was my recommendation for low-level, critical stuff so error would have been caught. Pure Java with AOT compiler would’ve been fine, albeit slower. Article also notes that ALGOL, the grandfather of languages like C and Go, also had bounds checking. Hoare, its co-designer and a C.S. legend, said this about it:

“A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interest of efficiency on production runs. Unanimously, they urged us not to—they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law.”

Another note was that certain tagged architectures, like Burroughs B5500 I’ve often referenced, supported it at the hardware instruction level. So, I actually could blame the assembly language for this one. 😉

“The only language that fits what is needed for this kind of task is DCALGOL…”

Haha nice. I heard that platform costs trillions to build, but only millions to wield.

Nick P • April 18, 2014 9:36 PM

@ Mbck

“And the bounds-checking error, or lack thereof, would have manifested itself with the length difference being the other way: the malloc’ed buffer could have been smaller than the one received.”

The gist of what I was saying was “Would a safe (dynamic checked) or managed language have prevented it, caught it at runtime, or gave the attacker the memory? And if it was coded as was typical in that language as well.” Certain languages handle it way better than C in both directions on bounds checking IIRC. Of course, I could be wrong about that.

“Interestingly, if memory serves, the Intel 80286 did support segmented memory, and paged memory only became available with the 80386. So the compilers could have assigned separate segments to each object – but the market (and memory sizes etc.) was not ready for that. Instead, we are left with paging, which I think dates back to the OS/360 and before. BTW, AFAIK, this OS is still with us. Mainframe designs never die.”

Intel still kept supporting the segmentation model. The GEMSOS security kernel (and I think XTS-400 STOP OS) used it to enhance security. The Native Client architecture (2009) that sandboxes Chrome used segments, too, noting that they’re a very efficient for such things. Matter of fact, an Intel document said on Atom processors unprotected access is 1 cycle, segments 2 cycles, and paging 8 cycles. So, it’s still a very efficient protection. That said, AMD eventually ditched it and most recent Intel processors might have. I’m not sure.

Burroughs B5000 had segments in 1961 so it was probably the first. (Many firsts with that one.) The IBM System/360 used keyed memory where a page of memory is associated with a key and a process needs to have the key to access it. Depending on implementation, the concept might involve several keys with a mix of hardware and software enforcement. PA-RISC and Itanium have that feature, too. IBM System Z and Secure 64’s SourceT both use this feature extensively inside the operating system for reliability & security.

“The semantics of these is not supported easily by hardware and requires a little more than general-purpose registers and linearly addressed memory.”

P-code Pascal was ported to something like 70 architectures, 8-bit to mainframes, per Wirth. So, these kinds of languages can work fine with plenty of hardware profiles, amazingly so in case of P-code. They might take more overhead, though, as they’re not just throwing bits around. (eg safety checks, structuring)

“When you needed a local buffer, you declared it at a higher lexical level – it was allocated on your process’ stack, no garbage collection required. The OS could address your data, you could not even construct an address to get to the OS data from an app.”

I didn’t know that. Thanks for the info as I’m quite interested in Burroughs architecture. I keep referencing it here as it’s far superior to most systems today in terms of security and support for high level languages. I think it was just too far ahead of its time. Check out this advertisement I found recently. Feels strange and neat to look back in time at something that tried to look forward in time.

“This is similar to the design of the THE operating system (the Wikipedia article is good.)”

That and A1-class systems are how I learned layering back in the day. 😉

“No, C is not a descendant of ALGOL. It is a descendant of PDP-11 Assembler, with a little syntactic sugar added to make it tasty.”

C is a decendent of B, a variant of BCPL. BCPL was a watered down version of CPL to make it easier to compile. Strachey et al, per their paper on CPL, required readers to be familiar with ALGOL 60 as CPL was heavily influenced by it, although was more complex. The lineage is ALGOL60->CPL->BCPL->B->C. So, they’re related. It’s just that ALGOL good design was so mutated and watered down that the end result looked like cross-platform assembler for, say, a PDP-11. 😉 And it’s safety, maintainability, and easy of integration follows from this. It’s real fast though!

Nick P • April 21, 2014 1:23 PM

@ Mbck

“On the Large Systems, I still would recommend the book by E. Organick on Computer System Organization ACM Monograph, . The notes by Jack Allweiss ( http://jack.hoa.org/hojaa/b5900.htm) are a more direct narrative of the environment where the Large Systems philosophy developed.”

Links dead. Thanks for the book reference. I’ll look into it sometime.

“The Large Systems Architecture (e-mode) survives to this day in the Unisys Libra/MCP systems. ”

Sort of. I’ve looked into them. They’re more like current machines that emulate the old ones. The biggest strength of B5000 line was that it enforced in hardware the foundation of system safety/security. Changing that to what’s essentially a virtual machine… well, look at Java. 😉

“To get information about how these machines work is essentially impossible to do.”

There’s plenty of information out there. I got a lot of technical information just Googling “Burroughs architecture,” “B5000,” and so on. There’s also the Capability-based security book online free that details many descripter- and capability-architectures. For composing it into a NUMA or mainframe machine, I don’t think we need to know how Burroughs/Unisys did it as much as look at similar machines with public info. For NUMA or interconnects, I always thought SGI was lightyears ahead of the competition so I’d copy them. There’s also many academic papers, prototypes, designs, etc for building large systems.

So, it doesn’t worry me. We only need to understand at an abstract level how they worked. Then, improve the design to help cover today’s threats. Then, have pro’s build it, others evaluate it, and a fab produce it. Simple as that. Expensive, though.

“I take note of your remark about P-code; but P-code is an interpreter, and therefore incurs a penalty compared to running directly on the hardware: This is what I was aiming at. Recent languages lay a thin layer on top of the flat-memory-and-registers hardware model and try to stick to it as closely as possible – witness the amazing results of work in code optimization.”

Definitely a penalty and what you say about mainstream systems languages is true. Compiler science has narrowed the gap you mention more than ever. Hope isn’t lost for robust systems programming on mainstream architectures. We at least have the likes of Ada and Modula for safe[r] systems programming with little performance hit. There’s others in development. I’d rather have hardware support, though.

“IMHO, because of this idea of squeezing the latest instruction cycle out of code, we lost sight of code robustness. In the meantime, the notion that there could be a different architectural model that the current one is completely forgotten, or, worse, taught as an aberration of people who didn’t know.”

Exactly. That’s totally what’s happened and is happening.

“It’s difficult to reintroduce ideas like block-structured languages and cactus stacks. “You can’t have programmers write malloc and free calls — THEREFORE you need automatic garbage collectors” is essentially impossible to fight.”

The battle I’ve been fighting… Funny you mentioned cactus stacks. I had totally forgotten about them. Looking it up, I found that Burroughs used that (more brilliance) and it was used in this parallel machine that Tandem had a part in. I didn’t know about this machine before. So, this conversation was both interesting and rewarding.

“… as you would expect from an assembler :-)”

Lol. They started with a good HLL for systems, then worked from there to re-invent assembler in more portable form. Man years of research well spent, eh? 😉

Nick P • May 5, 2014 1:04 AM

@ T

Actually, Katie’s rig following Buck’s advice to the letter might be totally secure from remote attackers. I just noticed this one imperfection in his scheme:

“First thing’s first, if you have any sort of device in between your server and the connection from your service provider, please remove it now! ”

Service providers typically ship a device, like a modem, that sits between the “server and the connection from… service provider.” Removing it disables the Internet. Removing the Internet should make the system quite secure from Internet threats, which make up 99+% of attacks. 😉

Of course, the system will still have trouble if it also has built-in wireless that automatically (and conveniently!) connects to nearby access points. cough Mac OS X cough I figure the latter feature would be included in Buck’s recommendations if they covered wireless networking.