---

Apparently not completely. Whew.

---

Intro and Introduction

Useful link back to the participant list

It is my understanding that we are supposed to use this Wiki to keep notes/comments/etc as the session progresses, with edit history to determine timestamps etc (should anyone care).

Name: Nicholas Weaver (Note, it's pronounced "Nick Weaver")
Institution: International Computer Science Institute
Email: nweaver [at the domain] icsi [dot] berkeley [dot] edu
Research Interests: FPGA architectures, system and network security, automatic detection and analysis of malcode (worm defense), high performance network-layer security.

Disclaimer: I may be bluntly offensive. Never take it personally, I'm just vocal. Also, I'm wrong 90% of the time.

---

Preintro comments: I generally believe that security is a system level property, and in particular, if the systems involve humans, a human level problem. (I don't do much research in human factors, simply because I'm not very good at that area, so I focus on the areas where I have some ability).

Composibility, which is the theme of this workshop, is an interesting problem as I believe that composition itself has often very interesting impacts on overall system security.

I also believe in specifying the threat model early on/at the start of system design. My usual model is "my Evil Twin" with a given set of objectives and a given suite of resources.

Finally, we all have a set of filters through which we view the world, and this affects our foucses. For me, my filter is "Malice": Some fraction of the people out there are simply put, sociopaths. Some have worldviews diametrically opposed to our own. Some people are reckless, ignorant, petty, cruel. In short, people WANT to do bad things. And other people just don't care. Thus pretty much everything I say is through this filter.

---

Desgin decision: I'm going to put all comments in this page (rather than using subpages) unless there is a significant asside.

---

Intro

Helen Gill, NSF

Comments: The distinction between different communities ("Stovepipes") probably is a key one. I'm not sure if there is an easy solution, but it needs to be addressed.

---

Session 1

Comment (I realize as I go on this is a GLOBAL comment): My "Malice" filter kicks in with component based design. Can you really do component based design when the desired result (security) is a global property of the entire system?

What effect does composition really have on desired security properties? There are plenty of examples where combined composition increases strength, or destroys all strength, of the security system.

Comment again: WHAT IS THE THREAT MODEL? a component which uses too much resources, as a bug? A component which could be attacked? Why would it be attacked? etc etc etc.

So far, it seems to be "Confidence in a benign environment" problems: components may be malfunctioning, but not malicious. EG, resource scheduling can keep a runaway component from damaging others (enforcing isolation). But it can't stop a corrupted component from causing system level failure. ("Safety/security is a global property, but can be disrupted by local effects")

Neeraj Suri: Composability needs consideration of the environment. Very good point.

---

Time for some random, antagonistic, grossly uninformed (and probably wrong) speculation...

Is composition fundimentally the wrong metaphor for building a safe or secure system?

Why? Security and safety are global properties: they can be affected by bad local behavior, but even with 100% good local behavior, there isn't guarenteed safety or security. Likewise, it may be possible to take components with bad behavior and create a good system...

Thus is a better metaphor decomposition? Start with the top in creating a model of objectives and an analysis of what properties are desired (E.G. what Jan Jurgens's presentation proposes) and then decompose the system into pieces, attempting to match the pieces with components which exist? Do we need to commit to an initial top down process??? Is this essential for safety and security????

---

Luca Carloni

You can do automatic pipelining (retiming) for composition as well, although this has limitation, you may have to add latency to get to timing.

Patience: Can one statically guarentee no deadlock? Probably...

Realtime constraints CAN be satisfied by a retiming/explicit pipeline model instead.

---

Jouni Keronen

Obligatory observation: Is converging it all onto the same network a good idea at all? It's happening....

SCADA scares me: Its standard COTS OS, and a few vendors. With safety being a global property (so the devices have to trust the SCADA controller), this worries me.

I'm not sure if more R&D can solve the problem (the vulnerabilities of the "SCADA systems now"), if the systems are fundimentally built wrong!

One jump between the office network and the automation networks is SOP?

(ASSIDE: Why isn't Sandia Labs folks here?)

Lifecycle issues: How much Windows 95/98/NT3 is still being used in critical SCADA systems?

Vendor required for open systems? Have anyone READ the EULAs from Microsoft? How is Microsoft's contracted support any good? They guarentee nothing. (Although shockingly enough, it doesn't say "Not for use in nuclear power plants/medical/etc without prior arrangement" in the EULA. Xilinx does (or at least did)).

Cost vs reliability: Are we just UNWILLING TO PAY for reliability & security?

EG, able to patch a running OS: thats the whole point of mainframe systems is you pay a fortune for 99.99-99.999% uptime. These technologies seem to require just spending enough money. If the SCADA folk actually placed reliability & security above cost, IBM would happily design MiniMainframes.

Security for JUST 1-2 euro more/month on telecom? But might not security cost 2x the service? 10x? Security isn't necessarily cheap, especially since it is a system level problem.

---

Armando Colombo ("Smart Embedded Components")

My ignorant take: a bottom-up approach: build the blocks, then mcompose them in a distributed system.

On the other hand, this is manufacturing. Its not really security critical, and not necessarily safety critical (or that critical at least). I think a lot of the "fast customization" can be done between C&C (and other prototype->production fast-turnaround manufacturing) and outsourced assembly (humans are cheap, even in the US, an assembler type is <$25/hr)

---

UTC talk

Again, most doesn't actually seem to be safety/security critical in practice. Yeah, dynamically adjusting fire is cool, but the real use is just managing the AC vastly more efficiently.

---

Keijo Manninen

Process control systems

Nothing to note from me.

But nobody else is bothering by this point, so why am I still writing in the wiki. NOBODY looked at my Big Red Tag, at least enough to respond. I stand in the back of the room and NOBODY has the wiki loaded. The idea sounds really interesting, but the implementation is, IMO, a total failure.

---

Kowalewski

How really different are the 1500 variants? EG, is it like bots/viruses, where there are some handful of families and then customization?

---

OK, there are now a couple of Wikicomments, but not much. Maby 4-5. And only 1-2 have significant comments rather than a "who I am" placeholder.

We'll have to see at 4pm or so, but I'm definatly concluding that the workshopWiki is a failure, at least for this audience.

---

On Sensornets: I don't trust sensornets in a malicious environment, but they do seem very interesting in nonmalicious (but even perhaps safety critical, but if safety critical there may be motives for attacks)

For example, lets take a variant attacker/pursuit game (which would make DARPA happy as a cool demo, which I think I've heard the sensornet crowd mention), where both teams are on a wooded paintball field, and its a painball game, with one team with the sensor net information.

Even without playing games with the sensors, just knowing where people are is not necessarily enough. If the red team is better players/better trained, information may not be enough. But even more so, the red team could detect where the sensors are (they have to broadcast), disable/throw them, and move back, creating dead zones.

Likewise, suppose its detecting "tanks": the rule is every HOPPER (the part that stores the paintballs) has a sensor mote on it to broadcast the position. The red team could pull a deception operation by removing the hoppers and manually loading, with a few members moving all the hoppers around to make the tanks look still active.

But more powerful still is worming the sensornet (where the red team has prep time): Since its P2P code, and there is PROBABLY a bug, the attacker captures a node, extracts key material, and now communicates/coopts the sensor net, both to track the blue force (initially, with just node access), to potentially feeding false information to the sensor net (blue team members reported as red-team members. Hello induced friendly fire!), or just shutting it down completely.

Part of the big issue with sensornets is they can fail VERY brittle, WITHOUT observability, due to worms. You don't have enough additional visibility to even detect that such things happer, compared with say a wired network where you can, at least theoretically, get good visibility into the network. Sastry's slides didn't mention "Worms" that I saw.

---

And what [expletive deleted] would do a drive-by-WIRELESS car?

---

Is making these systems of embedded systems, more complex, less controlled (more wireless) a good thing at all? Sholud instead of trying to build such systems and making them robust, should we focus on fighting the trend of insane complexity?

---

I should register www.scada_rootkit.com

---

4:30 pm, no major wiki edits by anyone else in the past few hours. Yes, the Wiki experiment is a failure. I'm not sure how to make a workshop where people WOULD use the Wiki, because it does seem useful.

It might just me I'm more outgoing/rant-happy, and this works well for rant-happy me to spew my garbage without interrupting speakers.