[spoilers]What happens when Shannon Foraker meets...

kzt wrote:That actually won't work, because the interesting stuff is on drive & core b. So once you suborn Flash or whatever minor utility on core b you have access to the actual data of interest.

And depending on how sophisticated and patient the attacker is there are ways to corrupt even secure firmware.

Ever read Ken Thompson's "Reflections on Trusting Trust"?

This is why I decided not to continue the discussion. Remember the "two thousand years" mantra? Discussing why our current designs can't manage it assumes that we're the smartest apes on the block and nobody who comes after us will have any of those "unpredictable" insights that makes an unresolvable problem easy.

I could list a huge number of problems with our current system. So could anyone with a decent computer security background, and that would be a much longer list. Most of them are solvable with the political will to say things like "C requires super-human programmers if you want a secure program at an affordable price; we need a low level language that doesn't require programmers to not make any mistakes, anywhere, at any time," and then back it up with action. Or say "a currently secure pass-phrase needs to be at least 5 words and 30 characters, so any program that doesn't accept pass-phrases of at least 45 characters is violating standards. You won't like the fines you'll get for either selling or using one."

It's easy to think that the problems are unresolvable. In fact, that seems to be a common belief, and that belief, in turn, has some of the characteristics of a self-fulfilling prophecy.

David is telling an interesting story. This is a side issue.

As someone who has both worked physical security and computer security, the best metaphor I can use is

"The most secure building is the one with no doors".

Ie, a useless building.

There is always going to be a tradeoff between utility and security, and from what we've seen about how space warfare works in the Honorverse, being the officer in charge of fleet tacnet is like having "root" on a Unix machine, or DBA privileges in an Oracle database with respect to the sensors and fire control of every ship in the fleet.

With power comes trusted users. With trusted users comes the chance for mischief if they turn on you.

Even with the dumb Statesec setup, Harkness had to be a trusted user of something that was on their internal network to do any damage. (He had privilege to create, edit and compile code there. That's powerful stuff even if it's supposed to be limited to a sandbox)

You can make a perfect programming language that prevents all outside hacking attempts no matter who writes the code(maybe, seems impossible to me but I guess it is theoretically possible in 2000 years). But the language of the code can't prevent trusted users from doing stuff similar to what they're allowed to do in order to do their jobs.

After doing nearly 20 years of IT in one company, I personally have a crapload of access and a lot of ways to do damage. This is in spite of frequent audits, reviews etc of access to strip anything not needed explicitly. At a minimum, I have shell access inside the firewall and the equivalent of IP addresses to most of the critical systems in the company. I could do a DDOS attack pretty easily. I could use development and test systems all over the company to juice the power of it. Also in spite of various efforts to limit sensitive data in dev/test envts, the test data has to be realistic in volume and type or the code will fail to edge conditions or perform badly in production. So I have a lot of visibility into how the company does business that might be interesting to a competitor.

If I was a datacenter guy, or sysadmin I could do a lot more damage.

You have to trust people with power to get anything useful out of your computer systems. It's the nature of the beast. We actually haven't seen any examples of people hacking "from the outside" in the Honorverse that weren't things more like data correlation and pattern matching of public information. All of the really big hacks were insiders. The really big covert ops coups involved human operatives physically doing stuff.

The big hacks:

1. Tampering with diplomatic messages. Required access of Secretary of State and a physical copy of the Manticore diplomatic seals.

2. Tampering with Tepes. Required ability to compile, deploy and run code on the main network + fewer physical firewalls than perhaps would be prudent. Still didn't affect the Brig or any systems not physically attached to the Tepes (eg, the small craft, personal cell phones etc). Since most of what Harkness did was just shut everything down, it was probably along the lines of a DDOS attack, something relatively simple.

3. "oops". Done by the fleet tacnet officer. Nuff said.

As someone who has both worked physical security and computer security, the best metaphor I can use is

"The most secure building is the one with no doors".

To quote Mythbusters: "When in doubt, C4" =)

C4 is like suborning the janitor to attack the physical machinery in the datacenter with an axe. It works but they'll know they were hacked.

solbergb wrote:As someone who has both worked physical security and computer security, the best metaphor I can use is

"The most secure building is the one with no doors".

Ie, a useless building.

There is always going to be a tradeoff between utility and security

Why? You're assuming that current limitations are always going to be limitations.

solbergb wrote:


, and from what we've seen about how space warfare works in the Honorverse, being the officer in charge of fleet tacnet is like having "root" on a Unix machine, or DBA privileges in an Oracle database with respect to the sensors and fire control of every ship in the fleet.

The number of security gurus who have pointed out that "root" access on Unix is totally idiotic from a security viewpoint numbers in the hundreds, if not the thousands. A high security system would not have a superuser who is allowed to do anything. The root user's privileges would be strictly limited to creating sub-administrator accounts and assigning them privileges; he would be unable to run any program other than the system-provided program to do that.

solbergb wrote:With power comes trusted users. With trusted users comes the chance for mischief if they turn on you.

Have you ever heard of basic security principles like separation of responsibility, least privilege and similar? These are not new. The fact that current operating systems were designed without security in mind doesn't mean it can't be done.

As an exercise, I designed a set of privilege classes for a consumer computer that takes all of the usual security principles into account. It's quite different from existing systems, but it looks useable.

You might want to try that design exercise rather than assuming that your work on systems with pitifully inadequate security architecture and design is the way it has to be forever and ever.

JohnRoth wrote:The number of security gurus who have pointed out that "root" access on Unix is totally idiotic from a security viewpoint numbers in the hundreds, if not the thousands. A high security system would not have a superuser who is allowed to do anything. The root user's privileges would be strictly limited to creating sub-administrator accounts and assigning them privileges; he would be unable to run any program other than the system-provided program to do that.

So he creates a role that allows him to do whatever he wants. And then logs in as that user. It's actually fairly hard to come up with a way that prevents this that doesn't involve some sort of physical asset, which can be locked up in a vault and really require multiple people to access it.

Step one of security: Don't hire bad people.

JohnRoth wrote:

solbergb wrote:As someone who has both worked physical security and computer security, the best metaphor I can use is

"The most secure building is the one with no doors".

Ie, a useless building.

There is always going to be a tradeoff between utility and security

Why? You're assuming that current limitations are always going to be limitations.

Well, that security tradeoff is as old as civilization so yeah, I'm assuming that utility will always require some kind of trusted person in any security situation.

Most castles are taken by treachery, not by seige. There are aphorisms like this going back to the beginning of time.

It doesn't matter if the castle is a prehistoric hill fort or a modern military base. Look at Bradley Manning and what he leaked. He had access to the data, and he chose to walk off with it instead of leaving it alone like the regs assumed he would.

As long as people can do something useful with a secure system, the guy authorized to use the secure system will be able to do something bad with it if he goes rogue.

I would submit a fleet tac officer has a whole lot more "bad" available to them than the ship's cook, but you know, a cook can poison a lot of people too.

Separation of responsibilities doesn't help as much as you'd think. If one responsibility is "lock up the building at night", then that guy can in fact leave the door unlocked and the alarms off. Or he can burn the building down.

The only real defense is to not motivate your trusted users to betray you. Start by not being a dick to them.

Hm...and speaking of separation of responsibilities.

The fleet tac officer is the person who makes the fire plans. These are made well in advance of any shooting, including some for use when you don't even know who the enemy is going to be, for when you are surprised.

The tacnet leverages the networked power of the entire fleet to execute the plan, and overrides local control on weapon systems.

The person creating and executing the fire control plan needs:

read access to all sensors in the fleet

read and write access to all fire control telemetry links in the fleet. This includes updating missile instructions while they're in flight based on more recent sensor data.

read and write access to all offensive and defensive weapon systems (read the status of each weapon, write the commands that tell it how to traverse and when to fire, and in the case of missiles, what ammo to load in which order)

The fleet tac officer also does fleet simulation exercises, which require all of the above access plus write access to every sensor in the fleet, to replace their input with the simulation input.

If you can't figure out how to blow up a fleet with all that access, you aren't trying very hard. You can't build a system that simultaneously gives that access and also denies it. Because of the access to the sensors, any system that would have a failsafe can be overidden.

We've seen ships target their own by accident in fleet operations. Clearly the bias of a tacnet is to allow the weapons to fire once ordered to. I imagine you don't want an incoming missile to fool your fire control and convince it not to shoot by flashing an IIF signal similar enough to your fleet to lock your weapons down.

Mutinies suck. Try not to piss off the people you entrust with the big-ass weapons.

solbergb wrote:Hm...and speaking of separation of responsibilities.

The fleet tac officer is the person who makes the fire plans. These are made well in advance of any shooting, including some for use when you don't even know who the enemy is going to be, for when you are surprised.

The tacnet leverages the networked power of the entire fleet to execute the plan, and overrides local control on weapon systems.

I'd quibble about the word "override." This is a planned mode of operation, so there's no override involved. Point of view, I suppose.

solbergb wrote:The person creating and executing the fire control plan needs:

The fire control system needs all of this access. The person making the plans and signaling execution needs access to the fire control system appropriate to her assigned duties. A large number of other people are also going to have access to the same system, with authorizations likewise tailored to their assigned duties.

solbergb wrote:read access to all sensors in the fleet

read and write access to all fire control telemetry links in the fleet. This includes updating missile instructions while they're in flight based on more recent sensor data.

read and write access to all offensive and defensive weapon systems (read the status of each weapon, write the commands that tell it how to traverse and when to fire, and in the case of missiles, what ammo to load in which order)

The fleet tac officer also does fleet simulation exercises, which require all of the above access plus write access to every sensor in the fleet, to replace their input with the simulation input.

If you can't figure out how to blow up a fleet with all that access, you aren't trying very hard. You can't build a system that simultaneously gives that access and also denies it. Because of the access to the sensors, any system that would have a failsafe can be overidden.

If the people who designed and built the system make it easy, they aren't trying very hard either.

See above. The fire control officer does not need direct access to the sensors. She needs access to what the sensors are showing, but so do a lot of other people. From what we've seen, she may have access to "raw," that is, not processed, data and parallel systems for analyzing it.

solbergb wrote:We've seen ships target their own by accident in fleet operations. Clearly the bias of a tacnet is to allow the weapons to fire once ordered to. I imagine you don't want an incoming missile to fool your fire control and convince it not to shoot by flashing an IIF signal similar enough to your fleet to lock your weapons down.

It's certainly true that someone has to have the ability to tell the fire control system that a particular ship is friendly, or the opposite, but I'd think that would be the responsibility of the captain or the Officer of the Watch. The tac officer would only have that during the middle of a fight.

solbergb wrote:Mutinies suck. Try not to piss off the people you entrust with the big-ass weapons.

There is no flash on B. B has a set of non-writeable large ROM memories, which can write from the large ROM into the instruction core, and which are the only things that can write into the instruction core. Some of the old Commodore computers used part of this scheme. To change software coding, you have to install new hardware.

kzt wrote:That actually won't work, because the interesting stuff is on drive & core b. So once you suborn Flash or whatever minor utility on core b you have access to the actual data of interest.

And depending on how sophisticated and patient the attacker is there are ways to corrupt even secure firmware.

Ever read Ken Thompson's "Reflections on Trusting Trust"?