Jagged Thoughts | Dr. John Linwood Griffin

Security B-Sides is an odd duck series of workshops.  Are you:

1. Traveling to attend (or already living near) a major commercial security conference (RSA in San Francisco, Black Hat in Las Vegas, or SOURCE in Boston)?
2. Not particularly interested in attending any of the talks in the commercial security conference you’ve already paid hundreds of dollars to attend?
3. Unconcerned with any quality control issues that may arise in choosing a conference program via upvotes on Twitter?

Then you should attend B-Sides.

Okay, so it’s not as grim as I lay out above.  Earlier this month I attended Security B-Sides Boston (BSidesBOS 2013) on USSJoin’s imprimatur.  I felt the B-Sides program itself was weak, the hallway conversations were good, the keynotes were great, and the post-workshop reception was excellent.

But if I were on the B-Sides steering committee I would have B-Sides take place either immediately before or immediately after its symbiotic commercial conference.  In academic conferences you will often see a “core” conference with 1-day workshops before or after or both, meaning that attendees can optionally participate, without requiring separate travel, and without interfering with the conference they’ve already paid hundreds of dollars to attend.

My takeaways from the B-Sides workshop came from the two keynote talks.  Dr. Dan Geer (chief information security officer at In-Q-Tel)’s talk was one of the best keynotes I’ve ever seen.  Some of his thought-provoking points included:

• It’s far cheaper to keep all your data than to do selective deletion.  He implied that there is an economic incentive at work whose implications we need to understand:  As long as it’s cheaper to just keep everything (disks are cheap, and now cloud storage is cheap), people are going to just keep everything.  I’d thought about the save-everything concept before, but not from an economic perspective.
• When network intrusions are discovered, the important question is often “how long has this been going on?” instead of  “who is doing this?”  He implied that recovery was often more important than adversarial discovery (i.e., most people just want to revert affected systems to a known-good state, make sure that known holes are plugged, and move forward.)  And the times could be staggering; he noted a Symantec report that the average zero-day exploit is in use for 300 days before it is discovered.
• Could the U.S. corner the vulnerability market?  Geer made the fascinating suggestion that the U.S. buy every vulnerability on the market (offering 10 times market rates if needed) and immediately release them publicly.  His goal is to collapse the information asymmetry that has built up because of the economics of selling zero-day attacks.  He pined for the halcyon days of yore when zero-day attacks were discovered by hobbyists and released for fun (leading to “market efficiency” where everyone was on the same playing field when it came to technology decisions) rather than the days of today when they are sold for profit (leading to asymmetry, where known vulnerabilities are no longer public).
• “Security is the state of unmitigatable surprise.  Privacy is where you have the effective capacity to misrepresent yourself.  Freedom in the context of the Internet is the ability to reinvent yourself when you want.”  He suggested that each of us should have as many distinct, curated online identities as we can manage — definitely an interesting research area.  He made the fascinating suggestion of “try to erase things sometime,” for example by creating a Facebook profile…then later trying to delete it and all references to it.
• Observability is getting out of control and is not coming back.  He commented that facial recognition is viable at 500 meters, and iris identification at 50 meters.
• All security technology is dual use; technology itself is neutral and should be treated as such.  During my early days as a government contractor I similarly railed against the automatic (by executive order) top secret classifications applied to cyber weaponry and payloads — because doing so puts the knowledge out of reach of our network security defenders.  As it turns out, One Voice Railing usually isn’t the most effective way to change entrenched bureaucratic thinking.  (I haven’t really figured out what is the most effective way.)
• “Your choice is one big brother or many little brothers.  Choose wisely.”  This closing line is open to deep debate and interpretation; I’ve already had several interesting conversations about what Geer meant and what he’s implying.  My position is that his earlier points (e.g., observability is out of control and is not coming back) demonstrate that we’ve already crossed the Rubicon of “no anonymity, no privacy” — without even realizing it — and that it’s far too late to go back to a time where no brother will watch you.  Can anything be done?  I’m very interested in continuing to debate this question.

Mr. Josh Corman (director of security intelligence at Akamai) gave the second keynote.  Some of his interesting points included:

• Our dependence on software and IT is growing faster than our ability to secure it.  Although this assertion isn’t new, it always brings up an interesting debate: if you can’t secure the software, then what can you do instead?  (N-way voting?  Graceful degradation?  Multiple layers of encryption or authentication?  Auditing and forensic analyses?  Give up?)  A professor I knew gave everybody the root password on his systems, under the theory that since he knew it was insecure then he would only to use the computer as a flawed tool rather than as a vital piece of infrastructure.  Clearly the professor’s Zen-like approach wouldn’t solve everyone’s security conundrums, but the simplicity and power of his approach makes me think that there are alternative, unexplored, powerful ways to mitigate the imbalance of insecure and increasingly critical computer systems.
• HDMoore’s Law: Casual attacker power grows at the rate of Metasploit.  This observation was especially interesting: not only do defenders have to worry about an increase in vulnerabilities but they need to worry about an increase in baseline attacker sophistication, as open-source security-analysis tools grow in capability and complexity.
• “The bacon principle: Everything’s better with bacon.”  His observation here is that it is especially frustrating when designers introduce potential vulnerability vectors into a system for no useful reason.  As an example, he asks why an external medical devices needs to be configurable using Bluetooth when the device (a) doesn’t need to be frequently reconfigured and (b) could be just as easily configured using a wired [less permissive] connection.  The only thing Bluetooth (“bacon”) adds to such a safety-critical device is insecurity.
• Compliance regulations set the bar too low.  Corman asserts that the industry’s emphasis on PCI compliance (the payment card industry data security standard) means that we put the most resources towards protecting the least important information (credit card numbers).  It’s a double whammy:  Not only is there an incentive to only protect PCI information and systems, but there is no incentive to do better than the minimal set of legally-compliant protections.
• Is it time for the security community to organize and professionalize?  Corman railed against “charlatans” who draw attention to themselves (for example, by appearing on television) without having meaningful or true things to say.  He implied that the security community should work together to define and promulgate criteria, beyond security certifications, that could provide a quality control function for people claiming to represent security expertise and best practices.  (A controversial proposal!)  A decade ago I explored related conversations about the need to create licensed professional software engineers, both to incent members of our community to adhere to well-grounded and ethical principles in their practice & to provide the community and the state with engineers who assume the responsibility and risk over critical systems designs.
• “Do something!”  Corman closed by advocating for the security community to come together to shape the narrative of information security — especially in terms of lobbying to influence Governmental oversight and regulation — instead of letting other people do the lobbying and define the narrative.  He gave the example of unpopular security legislation like SOPA and PIPA: “you can either DDoS it [after the legislation is proposed] or you can supply draft language [to help make it good to begin with].”  I felt this was a great message for a keynote talk, especially in how it matches the influential message I heard from a professor at Carnegie Mellon (Dr. Philip Koopman) who fought successfully against adoption of the Uniform Computer Information Transactions Act and who exhorted me and my fellow students to be that person who stands up and fights on important issues when others remain silent.

All in all not a bad way to spend $20 and a Saturday’s worth of time.

Last week I attended the USENIX Annual Technical Conference and its affiliated workshops, all here in sunny Boston, Massachusetts.  Here were my takeaways from the conference:

• Have increases in processing speed and resources on individual computer systems changed the way that parallelizable problems should be split in distributed systems?  In a paper on the “seven deadly sins of cloud computing research”, Schwarzkopf et al. note (for sin #1) that “[even] If we satisfy ourselves that parallel processing is indeed necessary or beneficial, it is also worth considering whether distribution over multiple machines is required.  As Rowstron et al. recently pointed out, the rapid increase in RAM available in a single machine combined with large numbers of CPU cores per machine can make it economical and worthwhile to exploit local, rather than distributed, parallelism.”  The authors acknowledge that there is an advantage to distributed computation, but they note that “Modern many-core machines…can easily apply 48 or more CPUs to processing a 100+GB dataset entirely in memory, which already covers many practical use cases.”  I enjoyed this observation and I hope their observation inspires (additional) research on adaptive systems that can automatically partition a large cloud-oriented workload into a “local” component, sized appropriately for the resources on an individual node, and a “distributed” component for parallelization beyond locally-available resources.  Would it be worth pursuing the development such an adaptive system, especially in the face of unknown workloads and heterogeneous resource availability on different nodes—or is the problem intractable relative to the benefits of local multicore processing?

• Just because you have a bunch of cores doesn’t mean you should try to utilize all of them all of the time.  Lozi et al. identify two locking-related problems faced by multithreaded applications:  First, when locks are heavily contended (many threads trying to acquire a single lock) the overall performance suffers; second, each thread incurs cache misses when executing over the critical section protected by the lock.  Their interesting solution involves pinning that critical section onto a dedicated core that does nothing but run that critical section.  (The authors cite related work that does similar pinning of critical sections onto dedicated hardware; I found it especially useful to read Section 1 of Lozi’s paper for its description of related work.)  The authors further created a tool that modifies the C code of legacy applications “to replace lock acquisitions by optimized remote procedure calls to a dedicated server core.”  One of my favorite technical/research questions over the past decade is, given ever-increasing numbers of cores, “what will we do with all these cores?”—and I’ve truly enjoyed that the answer is often that using cores very inefficiently is often the best thing you can do for overall application/system performance.  Ananthanarayanan et al. presented a similar inefficiency argument for small clustered jobs executing in the cloud: “Building on the observation that clusters are underutilized, we take speculation to its logical extreme—run full clones of jobs to mitigate the effect of outliers.”  One dataset the authors studied had “outlier tasks that are 12 times slower than that job’s median task”; their simulation results showed a 47% improvement in completion time for small jobs at a cost of just 3% additional resources.

Figure 5 from “netmap: a novel framework for fast packet I/O” [Rizzo 2012]

• There are still (always?) plenty of opportunities for low-level optimization.  Luigi Rizzo presented best-paper-award-winning work on eliminating OS and driver overheads in order to send and receive packets at true 10 Gbps wire speed.  I love figures like the one shown above this paragraph, where a system both (a) blows away current approaches and (b) clearly maxes out the available resources with a minimum of fuss.  I found Figure 2 from this paper to be especially interesting:  The author measured the path and execution times for a network transmit all the way down from the sendto() system call to the ixgbe_xmit() function inside the network card driver, then used these measurements to determine where to focus his optimization efforts—those being to “[remove] per-packet dynamic memory allocations, removed by preallocating resources; [batch] system call overheads, amortized over large batches; and [eliminate] memory copies, eliminated by sharing buffers and metadata between kernel and userspace, while still protecting access to device registers and other kernel memory areas.”  None of these techniques are independently novel, but the author claims novelty in that his approach “is tightly integrated with existing operating system primitives, not tied to specific hardware, and easy to use and maintain.”  Given his previous success creating dummynet (now part of FreeBSD), I am curious to see whether his modified architecture makes its way into the official FreeBSD and Linux codebases.

• Capturing packets is apparently difficult, despite the years of practice we’ve had in doing so.  Two papers addressed aspects of efficiency and efficacy for packet capture:  Taylor et al. address the problem that “modern enterprise networks can easily produce terabytes of packet-level data each day, which makes efficient analysis of payload information difficult or impossible even in the best circumstances.”  Taylor’s solution involves aggregating and storing application-level information (DNS and HTTP session information) instead of storing the raw packets and later post-processing them.  Section 5 of the paper presents an interesting case study of how the authors used their tool to identify potentially compromised hosts on the University of North Carolina at Chapel Hill’s computer network.  Papadogiannakis et al. assert that “intrusion detection systems are susceptible to overloads, which can be induced by traffic spikes or algorithmic singularities triggered by carefully crafted malicious packets” and designed a packet pre-processing system that “gracefully responds to overload conditions by storing selected packets in secondary storage for later processing”.

• /bin/true can fail!  Miller et al. described their system-call-wrapping software that introduces “gremlins” as part of automated and deterministic software testing.  A gremlin causes system calls to return legitimate but unexpected responses, such as having the read() system call return only one byte at a time with each repeat call to read().  (The authors note that “This may happen if an interrupt occurs or if a slow device does not have all requested data immediately available.”)  During the authors’ testing they discovered that “the Linux dynamic loader [glibc] failed if it could not read an executable or shared library’s ELF header in one read().”  As a result, any program requiring dynamic libraries to load—including, apparently, /bin/true—fail whenever system calls are wrapped in this manner.  This fascinating result calls to mind Postel’s Law.

Table 1 from “Software Techniques for Avoiding Hardware Virtualization Exits” [Agesen 2012]

• Switching context to and from the hypervisor is still (somewhat) expensive.  The table above shows the “exit latency” for hardware virtualization processor extensions, which I believe Agesen et al. measured as the round-trip time to trap from guest mode, to the virtual machine monitor (VMM), then immediately back to the guest.  I was surprised that the numbers are still so high for recent-generation architectures.  Worse, the authors verbally speculated that, given the plateau with the Westmere and Sandy Bridge architectures, we may not see much further reduction in exit latency for future processor generations.  To address this high latency, Agesen described a scheme where the VMM attempts to find clusters of instructions-that-will-exit, and where the VMM handles such clusters collectively using only a single exit (instead of returning to guest mode after each handled instruction).  One example of such a cluster: “Most operating systems, including Windows and Linux, [update] 64 bit PTEs using two back-to-back 32 bit writes to memory….This results in two costly exits”; Agesen’s scheme collapses these into a single exit.  The authors are also able to handle complicated cases such as control flow logic between clustered instructions that exit.  I like a lot of work on virtual machines, but I especially liked this work for its elegance and immediate practicality.

• JLG’s favorite work: We finally have a usable interactive SSH terminal for cellular or other high-latency Internet connections.  Winstein et al. presented long-overdue work on making it easy to interact with remote computers using a cell phone.  The authors’ key innovation was to have the client (on the phone) do local echo, so that you see what you typed without having to wait 4 seconds (or 15 seconds or more) for the dang network to echo your characters back to you.  The authors further defined a communications protocol that preserves session state even over changes in the network (IP) address, meaning that your application will no longer freeze when your phone switches from a WiFi network to a cellular network.  Speaking metaphorically, this work is akin to diving into a pool of cool refreshing aloe cream after years of wading through hot and humid mosquito-laden swamps.  (As you can tell, I find high-latency networks troublesome and annoying.)  The authors themselves were surprised at how much interest the community has shown in their work: “Mosh is free software, available from http://mosh.mit.edu. It was downloaded more than 15,000 times in the first week of its release.”

• Several papers addressed the cost savings available to clients willing to micromanage their cloud computing allocations or reservations; dynamic reduction of resources is important too.  Among the more memorable:  Ou et al. describe how to use microbenchmark and application benchmarks to identify hardware heterogeneity (and resulting performance variation) within the same instance types in the Amazon Elastic Compute Cloud.  “By selecting better-performing instances to complete the same task, end-users of Amazon EC2 platform can achieve up to 30% cost saving.”  I also learned from Ou’s co-author Prof. Antti Ylä-Jääski that it is permissible to chain umlauted letters; however, I’ve been trying to work out exactly how to pronounce them.  Zhu et al. challenge the assumption that more cache is always better; they show that “given the skewed popularity distribution for data accesses, significant cost savings can be obtained by scaling the caching tier under dynamic load patterns”—for example, a “4x drop in load can result in 90% savings” in the amount of cache you need to provision to handle the reduced load.

In addition to the USENIX ATC I also attended portions of several workshops held coincident with the main conference, including HotStorage (4th workshop on hot topics in storage and file systems), HotCloud (4th workshop on hot topics in cloud computing), Cyberlaw (workshop on hot topics in cyberlaw), and WebApps (3rd conference on web application development).

At HotStorage I had the pleasure of watching Da Zheng, a student I work with at Johns Hopkins, present his latest work on “A Parallel Page Cache: IOPS and Caching for Multicore Systems“.

Since 2010 USENIX has held a “federated conferences week” where workshops like these take place in parallel with the main conference & where your admission fee to the main conference covers your admission to the workshops.  This idea works well, especially since USENIX in its modern incarnations has only a single track of talks.  Unfortunately, however, I came to feel that the “hot” workshops are no longer very hot—I was surprised at the dearth of risky, cutting-edge, groundbreaking, not-fully-fleshed-out ideas presented and the resulting lack of heated controversial (interesting) discussion.  (I did not attend the full workshops, however, so it could simply be that I missed the exciting papers and the stimulating discussions.)

I also sat in on the USENIX Association’s annual membership meeting.  Attendance at this year’s conference was well down from what I remember of the USENIX conference I attended a decade ago (USENIX conferences have been running since the 1970s), and I got the sense that USENIX is scrambling to figure out how to stay relevant, funded/sponsored, attractive to potential authors, and interesting to potential attendees.  The newly-elected USENIX board asked for community feedback so I sent the following thoughts:

Hi Usenix board,

I appreciate the opportunity to participate in your annual meeting earlier today. I wasn’t even aware that the meeting was taking place until one of the board members walked around the hallways trying to get people to attend. I otherwise would have thought that the “Usenix annual meeting” was some boring event like voting for FY13 officers or something. Maybe I missed a memo? Perhaps next year mention the annual meeting in the email blast you sent out beforehand. (When I was at ShmooCon earlier this year the conference organizer actually ran a well-attended session, as part of the conference, about how they run a conference — logistics, costs, etc. — and in that session encouraged the same kind of feedback that you all solicited during the meeting.)

One of the points I brought up in the meeting is that Usenix should place itself at the forefront of cool technology. If there is something awesome that people are using, Usenix could be one of the first to adopt it — both in terms of using the technology during a session (live simulcast, electronic audience interaction, etc.) and in terms of the actual technology demonstrations at the conference. Perhaps you could have a “release event” where people agreed to escrow their latest cool online/network/storage/cloud/whatever tools for a few months and then release them all in bulk at the conference? You could make it into a media/publicity event and give awards for the most Usenix-spirity tools.

My wife suggests that you hold regional gatherings simultaneously as part of a large distributed conference. So perhaps it’s difficult/expensive for me to fly out to WA for Usenix Security, but maybe it’d be easy for me to attend the “northeast regional Usenix Security conclave” where all the sessions from WA are simulcast to MA (or NY or DC) — e.g. hosted at a university somewhere. Even better would be to have a few speakers present their work *here* and have that simulcast to the main conference in WA. [Some USENIX members] would complain about this approach, but think of all the news lately about the massive online university courses — perhaps Usenix could be a leader/trendsetter/definer in massive online conferences.

If I can figure out how, I’d like to be involved in bridging the gap between the “rigorous” academic conference community and the “practical” community conference community. I’m giving a talk next month at a community conference, so I will try to lay the groundwork there by describing to the audience what conferences like Usenix are like. You know, YOU could try to speak at these conferences — e.g. [the USENIX president] could arrange to give an invited talk at OScon, talking about how ordinary hacker/programmer types can submit interesting work to Usenix and eventually see their name at the top of a real conference paper.

Anyway, I appreciate the challenges you face in staying relevant in the face of change. I agree with the lady from the back of the room who expressed that it doesn’t matter what Usenix was 25 years ago, what’s important is what Usenix is now and in the next few years. Good luck!

Within hours the USENIX president replied:

Thanks for your thoughtful mail and especially your desire to be part of the solution — that’s what we love about our members!

I think we got a lot of good feedback last night and there are some great ideas here — the idea of simulcasting to specific remote locales where we have regional events is intriguing to me. You’ve given the board and the staff much to think about and I hope we don’t let you down!

Last week I attended the Network and Distributed System Security (NDSS) Symposium in San Diego, California.  NDSS is generally considered one of the top-tier academic security conferences.  This was my second year in a row attending the symposium.

Things I learned or especially enjoyed are in boldface text below (you may safely skip the non-boldfaced text in the list):

1. What you publicly “Like” on Facebook makes it easy for someone to profile probable values for attributes you didn’t make public, including gender, relationship status, and age.  For example, as described by Chaabane et al., “single users share more interests than married ones.  In particular, a single user has an average of 9 music interests whereas a married user has only 5.79.”
2. Femtocells could represent a major vector for attacking or disrupting cellular infrastrcture.  I’ve used femtocells; they are great for having strong conversations in weak coverage areas, but to quote the conclusion of Golde et al.: “Deployed 3G femtocells already outnumber traditional 3G base stations globally, and their deployment is increasing rapidly. However, the security of these low-cost devices and the overall architecture seems poorly implemented in practice. They are inherently trusted, able to monitor and modify all communication passing through them, and with an ability to contact other femtocells through the VPN network…[However, it is well known that it is possible to get root level access to these devices.  We] evaluated and demonstrated attacks originating from a rogue femtocell and their impact on endusers and mobile operators. It is not only possible to intercept and modify mobile communication but also completely impersonate subscribers. Additionally, using the provided access to the operator network, we could leverage these attacks to a global scale, affect the network availability, and take control of a part of the femtocell infrastructure…We believe that attacks specifically targeting end-users are a major problem and almost impossible to mitigate by operators due to the nature of the current femtocell architecture. The only solution towards attacks against end-users would be to not treat the femtocell as a trusted device and rely on end-to-end encryption between the phone and the operator network. However, due to the nature of the 3G architecture and protocols and the large amount of required changes, it is probably not a practical solution.”
3. Appending padding bytes onto data, before encrypting the data, can be dangerous.  “Padding” is non-useful data appended to a message simply to ensure a minimum length message or to ensure the message ends on a byte-multiple boundary.  (Some encryption functions require such precisely sized input.)  As described by AlFardan and Paterson: “the padding oracle attack…exploits the MAC-then-Pad-then-Encrypt construction used by TLS and makes use of subtle timing differences that may arise in the cryptographic processing carried out during decryption, in order to glean information about the correctness or otherwise of the plaintext format underlying a target ciphertext.  Specifically, Canvel et al. used timing of encrypted TLS error messages in order to distinguish whether the padding occurring at the end of the plaintext was correctly formatted according to the TLS standard or not.  Using Vaudenay’s ideas, this padding oracle information can be leveraged to build a full plaintext recovery attack.”  AlFardan and Paterson’s paper described a padding oracle attack against two implementations of the DTLS (datagram transport layer security) protocol, resulting in full or partial plaintext recovery.
4. If you want people to click on your malicious link, keep it short and simple.  Onarlioglu et al. presented the results of their user-behavior study that showed, among other results: “When the participants did not have the technical knowledge to make an informed decision for a test and had to rely on their intuition, a very common trend was to make a guess based on the ‘size’, the ‘length’, or the ‘complexity’ of the artifacts involved. For example, a benign Amazon link was labeled as malicious by non-technical participants on the basis that the URL contained a crowded parameter string. Some of the comments included: ‘Too long and complicated.’, ‘It consists of many numbers.’, ‘It has lots of funny letters.’ and ‘It has a very long name and also has some unknown code in it.’. Many of these participants later said they would instead follow a malicious PayPal phishing URL because ‘It is simple.’, ‘Easy to read.’, ‘Clear obvious link.’ and it has a ‘Short address’. One participant made a direct comparison between the two links: ‘This is not dangerous, address is clear. [Amazon link] was dangerous because it was not like this.’. Interestingly, in some cases, the non-technical participants managed to avert attacks thanks to this strategy. For example, a number of participants concluded that a Facebook post containing a code injection attack was dangerous solely on the grounds that the link was ‘long’ and ‘confusing’…the majority of the non-techie group was not aware of the fact that a shortened URL could link to any destination on the web. Rather, they thought that TinyURL was the website that actually hosted the content.”
5. There needs to be more transparency into how lawful telephone interception systems are constructed and deployed.  At CCS two years ago a paper by Sherr et al. was presented that described a control-plane-DoS attack on CALEA systems; here Bates et al. propose a cryptography-based forensics engine for audit and accounting of CALEA systems.  As described by Bates et al.: “The inability to properly study deployed wiretap systems gives an advantage to those who wish to circumvent them; those who intend to illegally subvert a surveillance system are not usually constrained by the laws governing access to the wiretaps. Indeed, the limited amount of research that has looked at wiretap systems and standards has shown that existing wiretaps are vulnerable to unilateral countermeasures by the target of the wiretap, resulting in incorrect call records and/or omissions in audio recordings.”  Given the amount of light that people are shining on other infrastructure-critical systems such as smart meters and SCADA control systems, perhaps the time is ripe for giving lawful-intercept and monitoring systems the same treatment.
6. There are still cute ideas in hardware virtualization.  Sun et al. presented work (that followed the nifty Lockdown work by Vasudevan et al. at Carnegie Mellon, of which I was previously unaware) on using the ACPI S3 sleep mode as a BIOS-assisted method for switching between “running” OSes.  The idea is that when you want to switch from your “general web surfing” OS to your “bank access” OS, you simply suspend the first VM (to the S3 state) and then wake the second VM (from its sleep state).  Lockdown did the switch in 20 seconds using the S4 sleep mode; Sun et al.’s work on SecureSwitch does the switch in 6 seconds using the S3 sleep mode but requires some hardware modifications.  Given my interest in hardware virtualization, I particularly enjoyed learning about these two projects.  I also liked the three other systems-security papers presented in the same session: Lin et al. presented forensics work on discovering data structures in unmapped memory; El Defrawy et al. presented work on modifying low-end microcontrollers to provide inexpensive roots of trust for embedded systems; and Tian et al. presented a scheme for one virtual machine to continuously monitor another VM’s heap for evidence of buffer overflow.
7. Defensive systems that take active responses, such as the OSPF “fight-back” mechanism, can introduce new vulnerabilities as a result of these responses.  In some of my favorite work from the conference, Nakibly et al. described a new “Disguised LSA” attack against the Open Shortest Path First (OSPF) interior gateway protocol.  The authors first describe the OSPF “fight-back” mechanism: “Once a router receives an instance of its own LSA [link state advertisement] which is newer than the last instance it originated, it immediately advertises a newer instance of the LSA which cancels out the false one.”  However, “[The] OSPF spec states that two instances of an LSA [link state advertisement] are considered identical if they have the same values in the following three fields: Sequence Number, Checksum, and Age…all three relevant fields [are] predictable.”  In the Disguised LSA attack the authors first send a forged LSA (purportedly from a victim router) with sequence number N (call this “LSA-A”), then one second later send another forged LSA with sequence number N+1 (LSA-B).  When the victim router receives LSA-A it will fight back by sending a new LSA with sequence number N+1 (LSA-C).  But when the victim receives LSA-B it will ignore it as being a duplicate of LSA-C.  Meanwhile, any router that receives LSA-B before LSA-C will install (the attacker’s) LSA-B and discard (the victim’s) LSA-C as a duplicate.  Not all routers in an area will be poisoned by LSA-B, but the authors’ simulation suggests that 90% or more routers in an AS could be poisoned.  In other disrupting-networks work, Schuchard et al. presented a short paper on how an adversary can send legitimate but oddly-formed BGP messages to cause routers in an arbitrary network location to fall into one of a “variety of failure modes, ranging from severe performance degradation to the unrecoverable failure of all active routing sessions”; and Jiang et al. demonstrated that “a vulnerability affecting the large majority of popular DNS implementations which allows a malicious domain name [such as those used in] malicious activities such as phishing, malware propagation, and botnet command and control [to] stay resolvable long after it has been removed from the upper level servers”, even after the TTL for the domain name expires in DNS caches.
8. Hot topic 1:  Three papers discussed negative aspects of location privacy in cellular networks.  Kune et al. describe both an attack to determine the TMSI (temporary mobile subscriber identity) assigned to a telephone number in a GSM network, and a technique for monitoring PCCH (paging channel) traffic from a particular cell tower to determine if the subscriber is in the vicinity of (within a few kilometers of) that tower.  Bindschaedler et al. show empirically that recent research on “mix zones” — geographic areas in which users can mix or change their device identifiers such as IP and MAC addresses to hide their movement and ongoing communications — is not yet effective as a privacy preservation mechanism for cellular users.  Finally, in the words of Qian et al.: “An important class of attacks against cellular network infrastructures, i.e., signaling DoS attack, paging channel overload, and channel exhaustion attack, operates by sending low rate data traffic to a large number of mobile devices at a particular location to exhaust bottleneck resources…[We demonstrate] how to create a hit-list of reachable mobile IP addresses associated with the target location to facilitate such targeted DoS attacks.”  Of particular interest: “We show that 80% of the devices keep their device IPs for more than 4 hours, leaving ample time for attack reconnaissance” and that often on UMTS networks in large U.S. cities an attacker could “locate enough IPs to impose 2.5 to 3.5 times the normal load on the network.”
9. Hot topic 2:  Three papers discussed privacy preservation in cloud-based searching.  Chen et al. presented an interesting architecture where a private cloud and public cloud work are used together to perform a search over sensitive DNA information: “Inspired by the famous “seed-and-extend” method, our approach strategically splits a mapping task: the public cloud seeks exact matches between the keyed hash values of short read substrings (called seeds) and those of reference sequences to roughly position reads on the genome; the private cloud extends the seeds from these positions to find right alignments. Our novel seed-combination technique further moves most workload of this task to the public cloud. The new approach is found to work effectively against known inference attacks, and also easily scale to millions of reads.”  Lu, in addition to having the best opening to a Related Work section that I’ve ever read — “This section overviews related work; it can be skipped with no lack of continuity” — demonstrates “how to build a system that supports logarithmic search over encrypted data.”  This system “would allow a database owner to outsource its encrypted database to a cloud server. The owner would retain control over what records can be queried and by whom, by granting each authorized user a search token and a decryption key. A user would then present this token to cloud server who would use it to find encrypted matching records, while learning nothing else. A user could then use its owner-issued decryption key to learn the actual matching records.”  Finally, Stefanov et al. presented sort-of-cloud-related work on optimizing “Oblivious RAM”: “The goal of O-RAM is to completely hide the data access pattern (which blocks were read/written) from the server. In other words, each data read or write request will generate a completely random sequence of data accesses from the server’s perspective.”
10. Hot topic 3: Five papers discussed smartphone and/or app insecurity.  In work that had my jaw hitting the floor regarding the security design of production apps, Schrittwieser et al. “analyze nine popular mobile messaging and VoIP applications and evaluate their security models with a focus on authentication mechanisms. We find that a majority of the examined applications use the user’s phone number as a unique token to identify accounts, which further encumbers the implementation of security barriers. Finally, experimental results show that major security flaws exist in most of the tested applications, allowing attackers to hijack accounts, spoof sender-IDs or enumerate subscribers.”  Davi et al. described a control-flow integrity checker for smartphones with ARM processors: asserting “the basic safety property that the control-flow of a program follows only the legitimate paths determined in advance. If an adversary hijacks the control-flow, CFI enforcement can detect this divagation and prevent the attack.”  Zhou et al. analyzed the prevalence of malware in five Android app markets, including the official market and four popular alternative markets.  Two papers (Bugiel et al. and Grace et al.) address privilege-escalation problems in Android, where malicious applications are able to gain unapproved privileges either (Bugiel et al.) by colluding with other differently-privileged applications or (Grace et al.) by invoking APIs unexpectedly exported by the Android framework.  The presenter for the latter paper showed a video of a malicious application sending an SMS message and rebooting(!) the phone, both without holding any user-granted permissions.

There were three keynote speakers, whose messages were: (1) you’re a security professional so you need to be involved in publicly advocating one way or the other on security-related social issues; (2) the future [30 years ahead] will be a strange and interesting place and, since you’re a security researcher, you’ll help us get there; and (3) passwords are passé; if you’re not using two- (or more-)factor authentication then you’re not a good security practitioner.

I like NDSS because of the practical nature of the (mostly academic) work presented:  Much of the work feels innovative enough to advance the science of security, yet relevant and practical enough to immediately be integrated as useful extensions to existing commercial products.  Only 17% of submitted manuscripts were accepted for publication, so the quality of work presented was good.  Unfortunately, attendance is low — someone told me there were 210 people there, but I never heard the official count — so it is not as good a see-old-friends-and-make-new-ones event as, say, CCS.

Jagged Technology, LLC — tagline “We may be rough, but we’re sharp.” — was the name of the (first) company that I founded.

The website read:  “Jagged Technology executes R&D and provides consulting services in the fields of computer science, information processing, and computer systems software and hardware engineering.  Our areas of expertise include storage systems, security architectures, network components, and virtualization and operating systems.  Please contact [us] to discuss teaming, collaboration, sales, and employment opportunities.”

The company existed from late 2007 through early 2009.  My business plan was to pursue Small Business Innovative Research (SBIR) contract awards, following in the footsteps of the successful group I had previously worked for.  (That group had been part of a small government contracting business that had won numerous SBIR awards, but by the time I worked for them they had been acquired by a larger company and were no longer eligible to pursue SBIRs.)

I was wildly unsuccessful — other than in fulfilling my dream to found a business and work for myself — but I enjoyed every minute of it.  There were a few things I did right:

• I earned revenue!  Not very much, and I certainly came nowhere near turning a profit, but I was able to score some consulting work (evaluating storage system technologies and formulating research and product objectives) meaning that it wasn’t entirely a pipe dream.
• I had great mentors.  Before starting Jagged I had the privilege to work with and learn from Dr. Tiffany Frazier and Dr. Chuck Morefield.  Both were successful government-contracting entrepreneurs; Tiffany inspired me to dream big; Chuck took the time to sit down with me to describe what had worked for him when he took the plunge.  While running Jagged I relied on Dr. Greg Shannon‘s advice and assistance in creating winnable (if not winning) SBIR proposals and partnerships.
• I had good ideas.  After I dissolved the company and started working at my next job, I talked with one of the program managers on the phone (about the next round of SBIR solicitations).  The PM recognized my name and mentioned that he’d really liked what I submitted during the previous round.  (I managed not to scream “so why didn’t you fund it?!?”)

Of course, there were many things I did wrong, including:

• Not having a contract in hand before starting the company.  Nearly every successful government contractor I’ve talked with has said that they already had a contract lined up before filing the paperwork.  Doing so is especially important because it takes forever (often 9 months or longer) between when you first submit a proposal and when you start getting paid for the work.  I assumed that I’d be able quickly to win one or more contracts and that business would grow rapidly after that.
• Not having a reputation or past performance with the customers I targeted.  The ratio of submitted proposals to winning proposals was around 30:2 on many of the programs to which I proposed.  Often the program manager was already working with a contractor to develop the SBIR topic and announcement (so there’s 1 of the 2 awards likely already earmarked) so in essence I was competing against 29 other companies — many of whom were actual established companies with existing products, intellectual property, and history of contract performance.  And if the PM has actually worked with any of the other 29 companies on a previous program, then my already unfavorable odds get significantly worse.
• Overemphasizing the technical aspect of a proposal instead of all evaluated aspects.  SBIRs are evaluated equally on technical merit, feasibility of successful execution, and commercialization strategy.  My technical writeups were strong but the other two components (67% of the evaluation criteria) were usually weak; I typically listed only one or two people (me and a technical colleague) as lined up to execute the work and only one or two ideas on how I would partner with larger companies to commercialize the work.  My early proposals were especially unbalanced since I entered entrepreneurship with the idea that if I proposed a superior mousetrap then the money would beat a path to my door.  It would have made a significant difference in my chances for success if I had experienced partners as co-founders.
• Focusing my business plan on the SBIR program instead of building a diverse revenue stream.  It is hard for me today not to be severely disappointed in the SBIR program.  I poured significant time and money and opportunity into trying to come up with solutions to the government’s and military’s most urgent technological challenges; when I finally received a rejection notice (usually 9 to 12 months later) and I requested my legally required debrief, typically all I would get was a one-line memo saying that the evaluators “didn’t like my commercialization plan.”  Well, what didn’t they like and how can I do better next time?  Anyway, since I didn’t have contract in hand at the beginning (in retrospect) I would have been better served by focusing on commercially salable technology development — and sales — and using the SBIR program as a way to fund development of related but noncritical offshoot ideas.
• Not having opened a new cellular telephone account for business purposes.  To this day I get people calling my personal cell phone to try to sell widgets or web hosting to Jagged Technology.  On the plus side, registering your home address for a small business gets you signed up for all sorts of fascinating catalogs for boxes and shipping containers, plastic parts, and scientific glassware — I do enjoy receiving these catalogs, and it’s good to know that if I need a pallet of hazardous materials placards I know exactly whom to call.

The best thing to come out of having started Jagged Technology is a better understanding of how business works — for example, the complexity of balancing your product development schedule and projected contract or sales awards with the available resources (time, people, money) on hand to pursue the work; or the need to work in advance to establish a business area (for example by feeding ideas to program managers, and by visibly contributing to related product or community efforts) instead of simply responding to opportunities; or why a CEO spends his or her days talking with the chief finance officer, chief marketing officer, and chief operating officer instead of spending those days talking with project leads and engineers and salespeople.  It’s not all about better mousetraps.

Just as I feel that I’m a better car driver after having taken the Motorcycle Safety Foundation RiderCourse, I feel as though I’m a better researcher, mentor, and employee today thanks to having immersed myself in founding Jagged Technology and having worked hard for eighteen months to make it successful.

And here’s hoping to more success (or at least more revenue) next time!