Jagged Thoughts | Dr. John Linwood Griffin

January 30, 2012

ShmooCon 2012

Filed under: Reviews — JLG @ 5:36 PM

Last weekend I attended ShmooCon for the first time.

I enjoyed it, though it was more useful for a “street cred knowledge” standpoint that it was for developing enterprise-class security products.  My favorite items were:

  1. The best work presented:  “Credit card fraud: The contactless generation”:  This talk demonstrated, using actual equipment and an actual volunteer from the audience, that it is possible to create a working credit card replica without ever having physical access to one of the new “contactless” RFID credit cards.  Moreover, the foil sleeves that are supposed to prevent remote reading don’t work perfectly.  This area of continuing work truly scares me, since the technology is being used by banks to shift responsibility for fraud onto the consumers.  http://www.forbes.com/sites/andygreenberg/2012/01/30/hackers-demo-shows-how-easily-credit-cards-can-be-read-through-clothes-and-wallets/
  2. “Inside Apple’s MDM Black Box”:  The speaker has reverse-engineered the process by which MDM (mobile device management) traffic travels from an enterprise server, through Apple, to an iOS device; and demonstrated how third parties can build their own MDM devices instead of having to buy a big expensive product to do so.
  3. “A New Model for Enterprise Defense”:  One of the IT folks at Intel (Toby Kohlenberg) is pushing a solution to the multiple-fidelities-of-application-access problem.  Their main goal is to change access control decisions from a binary yes/no decision to a more nuanced approach based on “multilevel trust”.  For example, the goal is when a salesperson accesses corporate resources: From a coffee shop, they are limited only to viewing customer information and order status.  From a hotel room, they can modify orders and view pricing information, and all accesses are fully logged and audited.  From within a corporate site, they can modify customer information and change pricing information.  The talk was about how Intel has started a long multi-year effort to try to achieve this vision.  They’ve only just started, and unfortunately it seemed it would be a long time before their applications supported fine-grained access control.
  4. The announcement of www.routerpwn.com by a Mexican security researcher.  The purpose of Routerpwn is to demonstrate just how easy it is to break the security on many common routers; for example you click on a Javascript link and enter an IP address and boom, you’ve reset the administrative password.
  5. My favorite talk: Brendan O’Connor presented work on building low-cost sensor/wifi devices that can be stealthily placed or launched-by-drone into a target environment of interest.  (There’s nothing new about stealth placement, except he was able to make a workable device for $50, far cheaper than the usual $500 or $5000 devices.)  He also announced that he won one of the DARPA cyber fast track awards.  http://blog.ussjoin.com/2012/01/dropping-the-f-bomb.html

November 8, 2011

DARPA colloquium on future directions in cyber security

Filed under: Reviews — JLG @ 10:09 AM

I attended a DARPA cybersecurity workshop yesterday.  Three program managers spoke about programs that I found especially interesting:

1) Dan Roelker. “His research and development interests relate to cyberwarfare strategy, remote software deployment, network control theory, and binary analysis.” Two programs of note:

a) “Foundational cyberwarfare.” This topic includes exploit research, network analysis, planning and execution, cyberwarfare platform development, and visualization.

b) “Binary executable transforms.” This topic is narrowly focused on low-level code analysis and modification tools.

2) Peiter ‘Mudge’ Zatko. He’s introduced a new program designed to award small amounts of funding (~$50K) for small efforts (~months) in as little as four days after proposal submission, a timescale that I think is pretty exciting. The program:

c) “Cyber fast track.” “The program will accept proposals for all types of cyber security research and development. Of particular interest are efforts with the potential to reduce attack surface areas, reverse current asymmetries, or that are strategic, rather than tactical in nature. Proposed technologies may be hardware, software, or any combination thereof.”

3) Tim Fraser. “He is interested in cyber-security, specifically in using automation to give cyber defenders the same advantages in scope, speed, and scale that are presently too-often enjoyed only by the cyber attacker.” He has an ongoing program:

d) “Moving malware research forward.” I know one of his performers (SENTAR Inc.), they are working on malware classification technology that can extract distinguishing features from malware.

700 people attended the workshop. Other noteworthy themes from the event:

  • Across the board, DARPA seemed to be trying to be less quiet about its work on offensive cyber technologies — lending hope to our eventual ability to speak about such topics outside of a Top Secret darkroom. Several speakers (and me, previously) have mentioned that the CNE (computer network attack and exploitation) and CND (defense) sides of the house absolutely must inform each other to be effective. A speaker brought up the point that effective deterrence requires that your adversary understand what you are capable of.
  • Richard Clarke gave a fascinating talk where he questioned the U.S.’s ability to wage physical war on other countries when our own critical infrastructure is so devastatingly susceptible to cyber attack and disruption by those other countries.
  • He further stated that the only organization capable of defending the U.S. is the department of defense — that it is folly to rely on either the DHS or commercial entities themselves to adequately protect themselves against nation-state adversaries. Several people recommended that I read his new book, “Cyber War: The Next Threat to National Security and What to Do About It”.
  • Several speakers suggested that there needs to be true repercussions for anyone (a person or a state) that perpetuates a cyber attack against the United States. This is an interesting legal position that I had not heard advanced before.
  • Jim Gosler spoke to convey how we consistently underestimate the adversary, including his motives, resources, and capabilities. He gave an example of the Soviets successfully implanting keylogger-equivalents in typewriters in sensitive environments (project Gunman). If that is possible, anything is possible…and we need to adjust our thinking to what 100, or 1000, red teams could do in parallel with you as a target.

August 14, 2011

Black Hat USA 2011 and DEF CON 19

Filed under: Reviews — JLG @ 12:19 PM

This week I attended BH and DC for the first time.  My takeaways are:

1. Recent legislation and threats of lawsuits have had a chilling effect on the work presented at these conferences.

I felt there were very few “success stories” of systems hacked or security measures defeated.  Even the white-hat types who presented seemed subdued in the impact or scope of the projects they presented.  For example, one of my favorite talks was “Battery firmware hacking” by Dr. Charlie Miller; see for example http://hardware.slashdot.org/story/11/07/22/2021230/Apple-Laptops-Vulnerable-To-Battery-Firmware-Hack.  Miller described how he discovered the default unlock code for the battery firmware for Apple batteries, and showed some of the values that could be modified, and described the process of updating the firmware…but didn’t go so far as to show a video of a battery catching fire or exploding.  It seems implausible to me that he didn’t try it [he claimed he didn’t] — leading several attendees to opine that he was threatened with a lawsuit from Apple [as he allegedly was in previous years] if he did so.

2. Everyone under the sun identifies themselves as a “pen tester”.

Either there is far more work on penetration testing than I was aware of, or someone’s lyin’.  (One of my friends suggested that “pen tester” is also used as a G-rated term for someone who does computer network operations [CNO]-type work for hire, especially in the shady world of corporate espionage, so perhaps it’s just a catch-all euphemism.)  This made me wonder what competitive advantages are marketed in penetration testing — cost? speed? past performance? specialization by technology or by threat?

3. It’s probably a lot easier to be invited to speak at these conferences than you would think.

The quality of work presented was low, especially at DC.  If you are interested in presenting you need to have some sort of interesting hobby or side project.  Spend a couple of months hacking on an interesting enough idea and you could be standing on a stage in Vegas next summer.

4. It’s the year of the UAV!  (Unless that year was last year.)

There were at least two homebrew unmanned aerial vehicles on display, including a neat one that had vertical take-off and land (VTOL) capability.  One of the BH talks was “Aerial Cyber Apocalypse: If we can do it… they can too” where the presenters (Richard Perkins and Mike Tassey) detailed the construction of their inexpensive autonomous UAV with 10-pound payload (in their case, with signals intelligence equipment onboard).  Yikes.  Based on my previous experience with the DoD SBIR program, I anticipate a surge in Government solicitations to detect and deflect UAVs over the next 1-2 years in response to the commoditization of cheap payload-capable UAV technology.

5. There is an exciting new DARPA program for hackers to get fast and short-term funding for their hacking.

The usual contracting process (get a DUNS number, then get another number, then put an accounting system in place, then competitively bid on a proposal, then wait 3-6 months, then get a contract in place, then deliver in 6-12 months) can take upwards of 6-7 years to transition useful technology to the Government.  A DARPA program manager (Pieter “Mudge” Zatko) has pushed through a program (DARPA-RA-11-52) wherein small groups of hackers can receive small amounts of money in only two weeks, without having to jump through the usual contracting hoops, and you retain commercial rights to the resulting work.  I’ve heard people talk before about trying to streamline the Government funding process but this is the first concrete example I’ve seen…I hope it works.

6. There were many talks on mobile device and mobile infrastructure [in]security, especially focused on Apple products.

These included:  A talk on behavior-based intrusion detection systems (a complementary approach to signature-based IDSes) in the context of mobile devices, drawing on similar work done on regular OSes (system calls made, resources utilized, Internet destinations contacted); a talk discussing kernel-level exploitation of iPhones using previously disclosed vulnerabilities (uninitialized kernel variables, kernel stack buffer overflows, out of bound writes and kernel heap buffer overflows); a talk identifying vulnerabilities in the Android OS and in applications on the Android Market; a talk discussing the length of time (surprisingly, months) it takes for Android security updates to be installed by at least 50% of vulnerable systems; and a talk about reverse-engineering the enterprise-targeted “mobile device management (MDM)” infrastructure available for IT departments to use to push security policies onto iOS devices (and how the MDM process could be co-opted by a sophisticated attacker to gain access to a device).

The work I found most interesting is as follows:

A. “Virtualization Under Attack: Breaking out of KVM”

When virtualization is used for security and isolation between VMs, it is important that the hypervisor itself isn’t a vulnerability vector.  The speaker used a known vulnerability in the Linux KVM (kernel virtual machine) implementation — KVM supports hotplugging but allow you to unplug a device that shouldn’t be unplugged (the emulated real time clock), resulting in an exploitable dangling pointer — allowing them to run shellcode on the host.  I didn’t see this talk in person but reportedly the talk concluded with a “demonstration against a live KVM instance”.  Note that this doesn’t represent a vulnerability inherent to all hypervisors; just of an unpatched version of KVM.

B. “Beyond files undeleting: OWADE”

As described by the speakers:  “To reconstruct the users online activity from his hard-drive, we have developed OWADE (Offline Windows Analysis and Data Extraction), an open-source tool that is able to perform the advanced analysis required to extract the sensitive data stored by Windows, the browsers, and the instant messaging software.  OWADE decrypts and geolocates the historical WiFi data stored by Windows, providing a list of WiFi points the computer has accessed (including the locations of the access points to within 500 feet) and when each point was last accessed. It can also recover all the logins and passwords stored in popular browsers (Internet Explorer, Firefox, Safari, and Chrome) and instant messaging software (Skype, MSN live, Gtalk, etc.). Finally, it can reconstruct the users online activity by reconstructing their browsing history from various sources: browsers, the Windows registry, and the Windows certificate store.  In certain cases, OWADE is even able to partially recover the users data even when the user has utilized the browsers private mode.”

C. “Legal Aspects of Cybersecurity–(AKA) CYBERLAW: A Year in Review, Cases, issues, your questions my (alleged) answers”

The speaker provided a fascinating tour of cyber law precedent set over the previous year — for example, the decision in the Google wardriving case that just because a wireless network is unencrypted doesn’t mean that the general public is allowed to sniff traffic on the network; doing so may still violate the federal Wiretap Act if “the networks were configured to prevent the general public from gaining access to the data packets without the assistance of sophisticated technology.”  (I’m still trying to figure out what “configured to prevent” means in this case — does it mean the SSID wasn’t broadcast in the beacon frames?)

D. “SSL And The Future Of Authenticity”

The speaker spoke disparagingly about certificate-based authenticity in SSL.  Astonishingly, the author discovered (by looking up and cold-calling one of the original authors of SSL) that certificates were a last-minute design hack and were not thoroughly considered or evaluated.  As a result we have the certificate system we have today, where once you decide to trust a certificate authority you can never revoke that trust; see for example the Comodo hack earlier this year that resulted in false but valid certificates being issued in Iran for major sites (Google, Yahoo, Skype).  The speaker released a browser plugin that uses P2P-like multipath collaboration to determine the authenticity of the credentials presented by a remote site.  It will be interesting to see if the plugin catches on.

E. “Femtocells: A poisonous needle in the operator’s hay stack”

The speaker noted the rise of femtocells (home base stations to which your cellular phone can directly connect to make phone calls and transfer data) and described a fatal flaw in their design and deployment:  Whoever deployes such a device is able to overwrite the firmware on the femtocell and can interpose as a man-in-the-middle on voice and data communications; critically, the link between the phone and the femtocell is encrypted but the link between the femtocell and the cellular backend is *not*.  (The speakers demonstrated this using a real femtocell.)  Also, since the femtocell is a trusted element in the cellular network, it can both collect subscriber/location information from other femtocells on the network, and it can be used as a platform to DoS or otherwise attack the cellular network infrastructure.

F. “Lives On The Line: Defending Crisis Maps in Libya, Sudan, and Pakistan”

The speaker described “crisis mapping” — an interesting use of SMS messages for those in need to communicate with emergency responders during situations of disaster or civil unrest.  From the speaker’s paper: “Days after a 7.0 magnitude earthquake decimated the capital city of Haiti, a small team of technologists acquired the SMS shortcode 4636 and published the number throughout the disaster affected area. The project, which came to be known as Mission 4636, received over 50,000 SMS messages from citizens on the ground — messages containing calls for help from newly formed camps in open spaces such as sports fields and the locations of people trapped inside buildings.  The messages, most of which were received in Haitian Kreyol, were translated by an online team of over 1000 members of the Haitian diaspora collected through Facebook, then geolocated by additional online volunteers to pinpoint the location where the messages originated.  The processed messages were then forwarded to relief agencies on the ground[.]  Those reports enabled the response agencies to develop situational awareness on the ground and determine where aid was most needed.”  The speaker highlights unsolved vulnerabilities in crisis mapping (organization and authentication; platform choice and location; message collection, processing and presentation) and called for standardization work to address these vulnerabilities.

G. “Apple iOS Security Evaluation: Vulnerability Analysis and Data Encryption”

This work is of interest to anyone doing application development for the iOS platform; the paper surveys iOS security features including address space layout randomization (ASLR), code signing, sandboxing, and encryption.  Regarding encryption, the author concludes: “The Data Protection API in iOS is a well designed foundation that enables iOS applications to easily declare which files and Keychain items contain sensitive information and should be protected when not immediately needed. There are no obvious flaws in its design or use of cryptography. It is, however, too sparingly used by the built-in applications in iOS 4, let alone by third-party applications. This leaves the vast majority of data stored on a lost device subject to recovery if a remote wipe command is not sent in time.  The default iOS simple four-digit passcodes can be guessed in under 20 minutes using freely available tools, which will allow the attacker will physical access to the device to also decrypt any files or items in the Keychain that are protected using the Data Protection API. For this reason, it is crucial that sufficiently complex passcodes be used on all iOS devices.  Even with sufficiently complex passcodes, there are a number of sensitive passwords that may be recovered from a lost device, including passwords for Microsoft Exchange accounts, VPN shared secrets, and WiFi WPA passwords. This should be taken into account and these passwords should be changed if an iOS device storing them is lost.”

H. “Security When Nano-seconds Count”

The speaker described the computing architecture (bleeding edge) and security implications (no security whatsoever) of high-frequency trading computers on Wall Street.  This is an environment where microsecond delays in processing or communications can result in huge amounts of dollar losses.  In the speaker’s words: “For nearly all installations, the usual perimeter defensive mechanisms will be completely absent.  You won’t find a firewall, you won’t see routers with ACLs, you won’t see IDS and frankly, anything that you’d recognize as a security tool.  The essential reason that security devices are largely (if not wholly) absent from most implementations is that the best the IT Security industry can offer falls short.  Most commercial firewalls process data and add a few milliseconds of additional latency.  In the vast majority of interconnection scenarios, a few milliseconds isn’t that much of a problem.  In the case of low latency trading, it’s about 100,000 times too slow.  In addition to products which simply do not support this mode of operation, there’s a skills gap in the practitioner space….”

I. “Bit-squatting: DNS Hijacking without exploitation”

The speaker argues that bit flips in memory are more common than you’d think — given the number of devices and the amount of RAM deployed in the world, the speaker estimates a bit-flip rate of approximately 600k bit-flips per hour.  To test whether bit flips were occurring in practice, the speaker registered 31 “bit-flipped” domains such as “mic2osoft.com” (one bit away from “microsoft.com”).  Surprisingly, the author saw about 50 web requests per day to these domains (after manually filtering out web vulnerability scanners, search engine crawlers, and other web spiders) that could be attributed to memory bit-flips.  I’m not convinced of the rigor of the authors’ work, but the result is neat and certainly warrants further investigation.

J. “Chip & PIN is definitely broken: Credit Card skimming and PIN harvesting in an EMV world”

The speakers presented truly terrifying work.  The “chip and PIN” system uses a smartcard credit card in combination with a user-supplied PIN to authenticate a credit or debit transaction.  Previous work showed that chip-and-PIN cards can be used successfully without knowing the PIN; this work demonstrated that skimmers (to capture the card data plus the PIN) are easy to build and use.  The “terrifying” part is the authors’ observation that banks are shifting liability to the consumer now that the PIN is used for authentication: “the cardholder is assumed to be liable unless they can unquestionably prove they were not present for the transaction, did not authorize the transaction, and did not inadvertently assist the transaction through PIN disclosure.”  They noted a case in June 2011 where a Canadian bank refused to void a fraudulent $81,276 transaction because “our records show that this was a chip-and-PIN transaction. This means [the customer] personal card and personal PIN number were used in carrying out this transaction. As a result, [the customer] is liable for the transaction.”  Two of the four authors (all European) had fraudulent activity on their chip-and-PIN cards in the month preceding their talk.

K. “Corporate Espionage for Dummies: The Hidden Threat of Embedded Web Servers”

In the past I’ve seen work on how much information is stored in a network on auxiliary devices such as printers, photocopiers, and VoIP systems.  The authors revisited this topic, looking specifically for embedded web servers on a network, and published a tool (BrEWS) to identify and enumerate these devices on a network.  What I found interesting about their work was their use of Shodan, a queryable commercial database that can be used to find publicly visible embedded web servers (by searching for unique strings in the web server headers returned by these devices).  The authors note that Google and other companies try to block results for such vulnerable systems, but someone who knows where to look (Shodan in this case; I was previously unaware of that service) can easily and inexpensively buy the search results of interest.

I’m told that the full proceedings (including videos) are usually posted on the BH and DC web sites later in the year:
https://www.blackhat.com/html/bh-us-11/bh-us-11-home.html
https://www.defcon.org/html/defcon-19/dc-19-index.html

Final thoughts:

OVERALL IMPRESSION: I’ve previously attended only academic security conferences (CCS, NDSS, USENIX Security, DSN) and had been told to expect something different at BH and DC (i.e., haxx0rz).  I wasn’t disappointed (there were haxx0rz aplenty) although overall I was less impressed than I had expected to be.  Much of the work was simply incomplete — the CFP for both conferences closed in May and it turns out to be common practice for speakers to submit incomplete/work-in-progress ideas while planning to complete the work (or demonstrate the cool result) by the time August rolls around…but unfortunately many people weren’t able to complete the work or show the cool result.  Add to that the “chilling effect” described above and overall I felt the conference leadership really needs to address the quality-of-work problem.  Still, I’m glad I attended both conferences & I’ve walked away with stronger skills and knowledge.

BH VALUE: The most valuable thing about Black Hat was the vendor floor.  Unlike other vendor floors I’ve seen, this one had genuine engineers and techie types manning the booths — meaning that attendees could ask nitty-gritty questions about the products and services hawked by the vendors and get useful answers.  Many of the major CNO or security players had a booth so I was able to get a feel for the state of the industry and especially the state of commercial products to support network defense and computer forensics.  BH also ran a contest that required you to visit at least 15 of the vendor booths which turns out to be a great way to force you to talk with folks you wouldn’t have otherwise.  On the downside, a problem with BH is that they run multiple tracks (around 8 tracks simultaneously over the two days) meaning you miss many of the talks you would want to see; fortunately many of the slides and papers are available on the conference CD.

The Black Hat briefings are expensive (~$2000) but they one of the leading venues for open CNO discussions.

DC VALUE: The most valuable thing about Def Con was what happened outside the talks.  The DC organizers work hard to give the event a spontaneous hacker vibe and to encourage spontaneous hacking (defined as “curiosity and exploration of cool things”).  So there was a room filled with soldering irons and electronics puzzles and challenges; there was a lockpicking room where you could buy lockpicking sets and locks to practice upon; there were contests everywhere and parties and movies every night and long lines and fifteen thousand reasonably hygienic people packed into a series of small rooms.  They even annually run an amateur radio exam session at DC (I took the exams and qualified for a General-class amateur radio license; I missed the Extra-class license by two questions out of 50).

Def Con is cheap ($150), is interesting, and is in a fun location (Vegas).  Of particular value is that many of the BH talks are repeated at DC.  Next year is their 20th conference and should be an especially good year to attend.

November 13, 2009

CCS 2009

Filed under: Reviews — JLG @ 9:31 PM

16th Conference on Computer and Communication Security (CCS’09)
Chicago, Illinois
November 9-13, 2009

CCS is one of the top international security conferences (example topics: detecting kernel rootkits, RFID, privacy and anonymization networks, botnets, cryptography).  It is held annually in November.  This year there were 315 submitted papers from 31 countries, of which 18% were accepted after peer review.

I’ve attended CCS twice (2006 and 2009).  It is one of the best conferences I’ve ever attended — I find that the speakers describe practical, cutting edge, informative results; I keep up with old acquaintances and meet new ones; I keep sharp and up-to-date as a research scientist.

Here are some of the major themes from this year:

* ASCII-compliant shellcode:  My favorite paper of the conference is “English Shellcode” where the authors developed a tool that takes malicious software as input and converts it into REAL ENGLISH PHRASES (taken from Wikipedia and Project Gutenberg) that execute natively on 32-bit x86.  If you read no other paper this year, you simply must read this paper, it is wack incredulous.  There was another paper that uses only valid ASCII characters for shellcode on the ARM architecture.  These demonstrations are important because ASCII (and especially English ASCII) is likely to be passed through by network intrusion detection systems.  The favorite paper is here:

http://www.cs.jhu.edu/~sam/ccs243-mason.pdf

* Cloud computing:  Few authors of cloud-related papers seemed to address the cloudiness of their work, instead (and disappointingly) discussing generic distributed computing principles under a cloud umbrella.  The best cloud talk I saw was Ian Foster, an invited speaker at the cloud security workshop, who described the transition from grid computing to cloud computing thus: grid was about federation, cloud is about infrastructure and hosting.  He pointed out that the grid folks did a good job of developing (e.g., medical research) applications and executing analyses, but that it is the advent of data distribution and sharing in the cloud that is a game-changer in cloud computing.

* Anonymous communication:  There were several talks analyzing the efficacy of anonymization networks (mix networks, remailers, Tor, onion routing).  My takeaway is that these techniques work very well for latency-insensitive traffic (such as email), only moderately well for latency-sensitive traffic (such as web browsing), and not very well yet for high-bandwidth traffic (such as VoIP).  My favorite work was a poster on “Preventing SSL Traffic Analysis with Realistic Cover Traffic” (Nabil Schear and Nikita Borisov) where the authors change the statistical profile of your encrypted traffic such that existing analyses (such as measuring keystroke latencies) are impossible.

* Off-client emulation:  Several speakers described a technique for client-server applications (such as game clients running on customers’ home computers) that help to ensure the correctness, robustness, or speed of the client application.  It’s impractical to run a complete copy of the client on the server (because one server handles many clients) so the authors generally create minimalist versions of the client (for example, a game client that contains no rendering code) that are server-efficient.  In the game example, the client would send the user’s commands (“turn left, walk forward”) to the server, where the minimalist client would verify that those commands didn’t result in an invalid state (such as walking through a wall) that would indicate cheating by the player.

* Function-call graphs:  These are well-known techniques for tracing how an application executes (create a graph of the control flow of an application).  The technique kept popping up during the conference: using them to identify when someone has violated your software license and included your source code in their application; using them inside a hypervisor to identify when a kernel rootkit is present in a virtual machine due to the different hypercalls).  One attendee I had lunch with was very critical of the function-call graph technique (using an argument I didn’t really follow) but otherwise the technique seems useful.

* Power grids:  The currently-hot topic in security research is power grids and smart meters.  There are at least projects at Penn State, Carnegie Mellon, Johns Hopkins, and I’m certain many other places.  There was a tutorial, a paper, and several posters all discussing security issues in the power grid.  The most interesting aspect to me was attacks against state estimators: the researchers described techniques to manipulate the system components involved in measuring and predicting the state of generators, transmission lines, etc.  However, the research community still suffers from a dearth of real-world information of how these networks operate and where the real vulnerabilities might be.

* RFID:  As we already know, it is possible to do RFID well but none of the actual deployed RFID implementations do it well.  One classic observation by a speaker was of the RFID-enabled drivers licenses issued in Washington State (in advance of the Winter Olympics) that include a KILL command that’s supposed to be set with a unique PIN but in reality is unset (using a default PIN)…meaning that anyone with a transmitter and sufficient power could kill a device.

* Ethical standards for security researchers:  One paper raised an ethical issue in its appendix (how can we do security research inside Amazon’s cloud computing infrastructure in a manner that doesn’t violate their terms of service?) and some researchers from the Stevens Institute have published a report and are organizing a workshop to investigate ethical standards for security researchers.  I didn’t really agree with many of the points made (my ethical line is drawn much further to the left: security researchers should have few constraints) but it was a hotly discussed and debated issue during the session breaks.

Wolfram Schulte at Microsoft Research gave an invited workshop talk on their Singularity OS project (reinventing the OS from scratch; using software-enforced isolation instead of relying on hardware memory management techniques).  It’s an interesting project but impractical since it would require a widescale by developers in such a way that very little development would happen for awhile.  The work was inspired by his team’s frustration on using best-practices formal verification (etc.) techniques for software development — or, taken another way, it was so frustrating when a blue-sky team tried to use existing techniques to develop and prove major software projects that they gave up.  That doesn’t bode well for using those techniques extensively in any real-world software development project (although they can still be very useful and insightful…just frustrating).

Also a shout-out to my student Brendan O’Connor for delivering a well-received talk on stock markets for reputation at the digital identity workshop.

November 14, 2008

Information Assurance Conference

Filed under: Reviews — JLG @ 8:53 PM

In November 2008 I attended an “Information Assurance Conference” in Arlington, Virginia. This was a non-refereed two-day workshop of 30-minute talks on policy-level IA issues in the DoD and homeland security environments. The most interesting takeaways were:

  • If you are an organization that wants information assurance, give someone the high-level independent power to veto (or vet) which applications are allowed to use the network.

The U.S. Marine Corps has an outstanding example of this power used successfully: “the HQMC IA division will be the single point of contact within the marine corps for IA program, policy matters and oversight…[Mr. Ray Letteer] has authority to approve or disapprove an application or system for connection to [all Marine Corps core networks].” And, according to Ray (the speaker), the USMC really has given him the teeth to enforce his team’s IA policies.

Such a position of course requires diplomacy and tact: Ray mentions that he carefully vets the classifications of potential vulnerabilities to make sure only applications with demonstrable and unmitigatable vulnerabilities are ultimately banned from the network; he describes his role as translating geek-speak to the senior officers to convey the need for the restrictions his team enforces.

After a cursory look I feel that this USMC approach could serve as an best-practices reference model for many other large organizations. Another speaker noted that the traditional corporate and DoD approach is to have local administration (each division-sized entity has its own IA unit as part of its IT function), whereas the military is moving toward a single unifying enforcement point staffed by well-trained operators. (I asked “isn’t homogeneity terrifying?”; other speakers responded that homogeneity doesn’t have to mean single-point-of-failure — they are not talking about one point of deployment, they are talking about unified policy across all points of deployment.)

  • If you need an ROI (return on investment) story to sell an IA strategy to your management, you’re in luck.

Three speakers emphasized the availability of ROI metrics. Joe Jarzombek described the free software assurance tools that are available from the Department of Homeland Security. As part of that effort DHS published seven articles on making a business case for software assurance (sample title “A Common Sense Way to Make the Business Case for Software Assurance”; click on the “Business Case” link at the above site) and recently held a workshop on the topic.

Two other speakers suggested taking a nonstandard approach in selling security investments to your upper management: instead of justifying your existence, focus on demonstrating your continued competence. For example, present graphical weekly metrics of how many port scans you thwarted or how many new security vulnerabilities were announced by antivirus companies that you prevented from affecting your network.

Or, pick some of the low-hanging fruit to impress the bosses: Dr. Eric Cole of Lockheed-Martin mentioned a client engagement where his team was asked to suggest architectural changes to a network that was operating at 99% utilization. After looking at the network traffic, his team simply blocked 74% of the outgoing connections (i.e., those connections which could not be traced to a business purpose). Nobody complained, and the utilization was reduced to 55% at no cost to the customer.

  • If you are not a member of senior management, you need to learn to speak the language of senior management.

This theme came up over and over during the workshop. “Speak the language of executives — translate your geek-speak into business objectives!” All I can say is: I agree.

Four other quick notes from the workshop:

Whitelisting: One speaker mentioned a trend toward whitelisting web sites as a means of IA in military computer networks. (Whitelisting is enumerating the list of acceptable sites and denying access to any other sites.) I hadn’t heard that before — can anyone confirm you’re seeing this?

COTS: Is COTS still on the rise? Some speakers and attendees noted a trend toward COTS software and hardware, chiefly for the purchase costs and especially the (comparatively low) maintenance costs. Others noted that there remain many applications, especially in classified domains, where commercial vendors are unwilling to tweak their product to fit the needs of the space, and/or there is too much inertia or turf-war to switch away from specialized development systems.

Metadata: I was delighted to see a talk about metadata by Carol Farrant, whose team is interested in collecting, analyzing, and using metadata in data management for the intelligence and military communities. Of the technologies I heard discussed during the workshop, this is the one whose core technologies are arguably the least developed in the research and commercial environments. Unfortunately her team is underfunded and understaffed, so she is actively seeking volunteers to help move things along. (She notes that in the past year she’s seen more volunteer interest on the topic than on anything else in her career.) This might be an opportunity for an academic to have a big influence on metadata use and tool development.

FPGAs: I’ve been a fan of programmable logic since working with FPGAs in Dr. Richard Chapman’s research lab at Auburn. The final speaker of the workshop, Jonathan Ellis, claimed that the moment is at hand for reconfigurable logic to be used the way it was always intended — specifically, actually reprogramming the chips (frequently) during normal operations. Vendors are currently working to make this possible (if I heard correctly: although the chips can support multiple independent execution units on them, they currently have to be completely wiped to be reprogrammed. Not for long.) FPGAs have come a long way in 10 years: he asserts that software toolkits for ease of programming and implementation — arguably the biggest barrier to their widespread use — are right around the corner.  He also noted that the current thinking is if you are building 100,000 or fewer units of something like cell phones, it’s more cost-effective and time-efficient to pump out FPGAs (instantly available and upgradable) than to send off for ASIC fabrication (expensive, two month lead time).

I thank the hosts of this event, Technology Training Corporation, for sending me a complementary pass to attend the workshop. (This workshop was similar to the “cyber security conference” I attended in June.) Overall I would likely not attend this workshop again, as I (as a practitioner of basic and advanced research) am not really in their target audience. People who I think would be interested are people involved in policy-level marketing and sales for large government contractors, Marc Krull, and government employees involved with large program development and management.

October 9, 2008

NSRC industry day

Filed under: Reviews — JLG @ 10:12 PM

This week I attended the 5th annual industry day at the Networking and Security Research Center (NSRC) at Penn State University. The event was similar in format to other industry days I’ve attended (CMU, Stony Brook) but with a more focused core of industry guests, primarily from telecom companies and large government contractors.

My main interest was in the work of professors Trent Jaeger and Patrick McDaniel of the Systems and Internet Infrastructure Security (SIIS) laboratory. Their students are working on several projects of interest to Jagged, including:

Another NSRC focus is on wireless networking research (cellular, sensor, 802.11, vehicular, you name it). An upside of their work is that it is strongly focused on real-world problems reported by companies — for example, CDMA2000-WiMAX internetworking. A related downside is that it wasn’t clear what academic (basic research) lessons could be drawn from some of the work; some of the results felt limited in scope and applicability to only a specific problem.

All the posters from the industry day are available here:

http://nsrc.cse.psu.edu/id08.html

The most interesting and controversial talk at the event was a keynote by Mr. Steven Chabinsky, the deputy director of the Joint Interagency Cyber Task Force. He advanced the idea that we as a nation have let ourselves be “seduced” by technology, by plowing ahead with deployments of untested and unreliable technology at critical infrastructure points without first fully understanding (or mitigating) the risks and consequences of failure. He called on us as researchers and companies to consider the full spectrum of threat, vulnerability, and consequence in our technological innovations. A lively discussion ensued after the talk regarding the economic incentives to deploy unreliable technology: several of the topics were:

  • Will better policy decisions be made when cyber risks are better understood? The speaker described a current lack of capabilities to quantify risk either as an absolute or a comparative measurement. This is especially true in low-risk but extremely-high-damage scenarios such as directed attacks against components of the power grid. I felt this observation makes an excellent point, and highlights a mental gap between the way that engineers think of technology and the way that decisionmakers compare among technologies. Perhaps the government should fund some new studies along these lines?
  • Where should the government draw the line between regulation and deregulation? There are several non-regulatory actions the government could take to constructively assist companies in developing hardened products (say, that control water processing plants), such as making supplemental development grants available to companies whose technology will be used in critical infrastructure. On one hand, I feel that government should more actively oversee and regulate (and pay for) these kinds of technologies. But perhaps the problem is more complex than I realize — e.g., perhaps one gets a qualitatively better product through open-market competition than one would through contract specification and regulatory compliance. Anyone have an opinion on this?

Mr. Chabinsky’s point was underscored later in the day in a talk on the Ohio EVEREST voting study. Patrick McDaniel discussed how the Help America Vote Act effectively caused an insufficiently-tested prototype technology (electronic voting machines) for a low-profit-margin customer (the government) to be thrust into mandatory and widespread use in a critical environment (the legitimacy of our democracy) in only a few years. He concluded (as concluded by Avi Rubin and others) that current systems are fundamentally flawed and unsecurable. In light of the above discussion, these fundamental flaws represent a failure of technologists (as well as many others) — both (a) in our inability to architect reliable systems and (b) in our inability to adequately inform public policy officials of the true readiness of proposed technologies.

This latter problem — coherently describing and conveying the capabilities and limitations of computer systems in a non-expert human-comprehensible manner — is one of the topics that has long interested me, especially in the context of information sharing in sensitive or classified environments. Anyone want to join us in working on this problem?

August 26, 2008

High end computing workshop

Filed under: Reviews — JLG @ 3:44 PM

In August 2008 I attended the HEC FSIO workshop on file system and I/O (FSIO) research in support of high-end computing (HEC).

This HEC focus was interesting for a systems guy like me — think “systems that run detailed atmospheric simulations for weather prediction” and like environments where such words as “parallel”, “(peta)scale”, and “throughput” are bandied about. (Sample presentation title: Improving scalability in parallel file systems for high end computing.)

The primary attendees and presenters were academic PIs funded under a joint NSF/DOE program called HECURA. This program chooses a new theme each year for its solicitations: last year’s was compilers; this fall’s will be FSIO (as it was three years ago). All presentations from this workshop are available here:

The work was all interesting but old; most of the work had been presented and discussed at the great conferences of yore. What I ended up enjoying the most from this workshop was an “Industry Storage Device Research Panel” with two fabulous presentations:

The above two talks are a great introduction to, respectively, the future of magnetic storage & the future of alternatives to magnetic storage.

The most interesting thing I learned is DOE’s archival storage model. If you want to archive something, you FTP PUT it onto an enormous server containing everything else that’s been archived in the last 60 years. If you want to retrieve it, you FTP GET it. (I didn’t learn how you locate the item you want, but there must be a standard naming scheme or an index — if you know please send me a note.) I chatted briefly with Mark Gary, data storage group leader at LLNL, about the differences between that model and all the digital preservation issues we touched upon in the class I co-taught this Spring (metadata generation, textual normalization, ontology standardization, language translation, QoS, security, access methods, historical ingest, etc.) Mark made the point that their KISS approach, while limited in functionality at first glance, both works well and continues to do exactly what their users need.

July 11, 2008

SIEVE: Software Insertion and Execution in Virtual Environments

Filed under: Reviews — JLG @ 3:06 PM

This research proposal by Jagged Technology was initially targeted to SBIR program OSD08-IA2. We continue to seek sponsorship for the proposed work. If you are interested in teaming with us on future proposals on related computer systems topics, please contact us.

1. Introduction

Computer system virtualization, long a staple of large-scale mainframe computing platforms, has exploded into the commodity and off-the-shelf markets due to the widespread and affordable availability of software and hardware products that enable virtualization. As with any major change, the implications of the widespread deployment of virtualization are yet ill-understood; work is urgently needed to quantify the new opportunities and risks posed by specific virtualization technologies.

In this “wild west” phase of the commodity use of virtualization technology, each of the three aspects of information security (availability, confidentiality, and integrity) are by necessity being revisited by research labs around the world. For example, here is a representative sampling of three ways information security changes under virtualization:

  • Availability. Virtualization enables the straightforward deployment and management of redundant and widely-distributed software components, increasing the availability of a critical computer service. (The PI has prior experience in this space.)
  • Confidentiality. The use of hypervisors (a.k.a. virtual machine monitors) adds a new software protection domain to hardware platforms. This enables software workloads to run in isolation even when time-sharing the hardware with other workloads. (The PI has prior experience in this space.)
  • Integrity. Any software running within this new protection domain has privileged (superuser) access to system memory and hardware resources. This access enables the creation of new software auditing tools that unobtrusively monitor software workloads in a virtual machine.

It is this latter example of software in a privileged protection domain that is of interest in this proposal. The desired outcome of this research is a quantification of an opportunity (injecting software into a virtual machine) and a risk (the detectability of such injection). Specifically, Jagged Technology proposes:

  • In Phase I, we will develop a software tool that runs inside a privileged protection domain. [Footnote: This could be from a privileged VM (in what are known as Type I hypervisors), from a host OS (in Type II VMMs), or from the hypervisor itself. In the approach described later in this proposal, our tool runs in a privileged VM.] This tool will manipulate data structures in the memory of an ordinary protection domain (a virtual machine), in order to covertly load and run general-purpose software within the virtual machine.
  • In Phase II, we will explore ways to detect the covert general-purpose software or to thwart the operation of our stealth-insertion tool. For example, this may include obfuscating the method by which the operating system maintains its queue of active and inactive processes, or accessing memory pages in a statistically random fashion to analyze the timing of page faults to those pages.

By covert, we mean primarily that an adversary is unable to read the contents of the memory locations containing the instructions or data used by our covert software, and secondarily that evidence in audit and system logs is minimized or removed to reduce the odds that the covert software will be detected. We assume that this adversary is able to run software with full administrative privileges (root access) inside one or more non-privileged virtual machines on the hardware platform. It may also be possible to use our approach to monitor one privileged VM from another VM, addressing the case where an adversary has administrative privileges inside the trusted computing base. However, we focus only on non-privileged virtual machines—the location where most military and commercial applications will actually be run—in this proposal.

2. Phase I objectives

We identify four base objectives for our Phase I work. The first pair of objectives involve the covert loading of software in a virtual environment:

  • Objective #1: Use software running in one virtual machine (VM–1) to insert executable code, including instructions and data, into another virtual machine (VM–2).
  • Objective #2: Prevent software in VM–2 from being able to read or otherwise obtain the instructions and data of the inserted code.

The second pair of objectives involve the covert execution of software in a virtual environment:

  • Objective #3: Use software running in VM–1 to cause the operating system in VM–2 to actually execute the inserted code.
  • Objective #4: Prevent software in VM–2 from using the operating system’s audit facilities to trace or track the execution of the inserted code.

3. Phase I work plan

We propose work to build a software tool that causes a rogue process to be covertly loaded into a Xen virtual machine running the Linux operating system, and further causes that rogue process to be covertly executed. This work addresses the four Phase I technical objectives and is organized into three tasks:

  • Task I: Architecture and documentation. Develop prototype algorithms for modifying the Linux OS structures and Xen page table entries to support covert insertion and execution of software into a virtual machine.
  • Task II: Covert insertion (objectives #1 and #2). Create a minimal software prototype to insert code into a VM from the Domain-0 VM. [Footnote: Domain-0 is a privileged virtual machine containing the Xen command-line system management tools and also the device drivers that coordinate with the real system hardware.] Demonstrate how the memory pages used by the code are protected against unauthorized access from other software components inside the VM.
  • Task III: Covert execution (objectives #3 and #4). Extend the minimal software prototype to externally cause the OS inside the VM to schedule and execute the code. Demonstrate how the OS audit facilities are bypassed or modified to hide the execution of the code.

This figure demonstrates a high-level view of the technique we will use to insert software into a virtual machine:

Overview of covert insertion and execution

 

3.1 Developmental and experimental platform

We plan to execute this project using the Linux operating system. We will covertly insert processes into a running instance of Linux and prevent other processes (or components of the Linux kernel) from accessing the memory of our covertly inserted processes. To create our virtual environment we will use the opensource Xen hypervisor (http://xen.org) deployed on systems with processors based on the Intel x86 architecture.

We note that nothing about our approach is specific to the use of Linux or Xen. We envision future work to extend the technology developed under this program into a multi-purpose tool that works with other operating system and hypervisor combinations.

Our approach does not depend on whether the processor supports hardware-assisted virtualization. Our tool will be designed to work on platforms that do or do not contain processors with Intel Virtualization Technology or with AMD Virtualization.

3.2 Task I: Architecture and documentation

We will create an architecture document describing the method by which our tool works. This document will be intended to provide the government with knowledge of this technique that lasts beyond the length of this contract. The document will describe the functional design of our prototype tool and provide software and hardware specifications for the execution environment in which our tool runs. As our prototype will be minimal due to the limited scope of the Phase I effort, this document will describe the tasks that will be necessary to refine and extend the prototype for commercial viability and to meet the Phase II objectives.

As part of this task we will create a list of candidate countermeasures to our tool’s operation, based on our insider knowledge from the process of creating the tool. This list will highlight the most promising of these countermeasures that could form a core component of the Phase II effort.

3.3 Task II: Covert insertion

By drawing on the introspection principles demonstrated by the Livewire prototype, the XenAccess monitoring library and other security projects designed to allow one VM to monitor another VM, we will create a well-documented minimal software prototype for covert insertion of a rogue process.

This prototype will use the Xen grant table page-management interface to map and modify the contents of the VM from within Domain-0. The prototype will analyze the Linux data structures inside the VM to create a rogue process and to determine which pages are currently available for assignment to the rogue process.

In our approach we will subtly modify the page table entries for the VM—specifically, changing entries to remove the “page present” bit—to cause Xen to trap page faults into our own page-fault handler. This approach is along the lines of the method used by the Shadow Walker rootkit to hide the existence of modified pages from the operating system.

As discussed in section 1, our primary definition of covert is that that an adversary is unable to read the contents of the memory locations containing the instructions or data used by our covert software. Our approach fulfills this definition of covert: pages containing our data are accessible inside the virtual machine, but we monitor and gate which processes are allowed to read those pages by trapping of the virtual machine’s page faults. If anyone other than our rogue process attempts to read the pages, we could overwrite the page contents before completing the page fault. We could even use this technique to have our rogue process share pages with the pages used by legitimate processes, further obscuring the insertion of the rogue memory contents.

We expect that some modifications we will need to make to the OS data structures would ordinarily require full-kernel locking for safety. Locking can be a noticeable event, so we will attempt to create a tool that leverages other events in the virtual environment (such as domain scheduling) to obviate the need for explicit locking. Our prototype will first hook the Xen VM scheduler and domain-management infrastructure to passively determine at what times it is safe to make modifications to the domain’s memory (i.e., when the domain is blocked or otherwise not scheduled). We will then investigate an algorithm for making on-the-fly modifications to the VM without needing to first quiesce the VM, by monitoring which process is active inside the VM and determining which pages are in that process’ working set. If the process changes during our modifications, our prototype will have the option of immediately pausing the domain to complete its work while avoiding overt detection. [Footnote: A more detailed option, to be explored in Phase II, is monitoring which processes are currently running on which processors, and only to pause the VM when it unexpectedly enters kernel mode or otherwise performs potentially unsafe actions.]

3.4 Task III: Covert execution

By drawing on the principles demonstrated by the Xenprobes library, the Kprobes framework, and other security projects designed to allow an administrator to hijack the scheduler, debug the operating system, or probe the execution of a Linux virtual machine, we will create a well-documented minimal software prototype for covert execution of a rogue process. This could involve either inserting a new process onto the scheduler’s queue, or if possible hijacking existing processes for brief amounts of time to cause them to execute work on our behalf.

The focus of this task is both to cause the process to be executed and to do what is possible to cover the tracks of that execution by limiting the amount of resources consumed by our rogue process and by modifying the audit logs kept by the operating system to erase any entries or values indicating that our process executed. This satisfies our secondary definition of covert, in that evidence in audit and system logs is minimized or removed to reduce the odds that the covert software will be detected. As we develop the software for this task, we will explore the limit of stealth execution—identifying what evidence is visible during the actual execution of a process (for example, system status entries in the /proc file system) and determining whether this real-time evidence can be spoofed or removed.

Quantifying the many ways that a process leaves evidence of its execution has benefits both in Phase I and in Phase II, where one of the tasks will be to develop countermeasures to a tool like ours based on information available to an adversary inside the virtual machine. There are many types of evidence that may be observable by an adversary. For example, one side effect of mapping one virtual machine’s memory page in another VM is that it could change the contents of the memory caches (in essence, VM–1 could potentially preload the L2 cache with data from pages that VM–2 will soon access), which would change the timing characteristics of operations that the second VM would perform. Our continued identification of these issues will be incorporated into the architecture document from Task I.

3.5 Discussion and alternate approaches

Our approach relies on the existence of an inviolate trusted computing base (TCB) on the target system—in other words, there is a privileged part of the overall virtualized system to which the adversary cannot ordinarily gain access. For example, operating systems inside a Xen guest domain (virtual machine) cannot ordinarily access memory owned by other virtual machines unless they are specifically authorized to do so by both the administrator of the other domain and by the hypervisor itself.

Requiring a TCB does not mean that we require any sort of Trusted Computing hardware or specialized software modules in the hypervisor. Rather, it emphasizes that our focus is on using virtualization to aid our task of hiding the existence of software from the most common-case vantage point where an adversary will have access. Once we have developed the capability to externally insert a process into a running kernel, our tool could be deployed in more elaborate environments such as on specialized external hardware.

There are a panoply of alternate approaches for the covert insertion of software. Two examples include:

  • An interesting aspect of certain virtualization (and virtualization detection) hacks, as well as a number of exploits, is their reliance on unmapped (or differently mapped) access to physical memory from devices. With more and more powerful devices on the bus, many of them sporting their own CPUs, an alternate type of virtualization attack involves the embedding of “undetectable” code in the firmware of these devices. This is particularly applicable to network cards with protocol offload functionality, since these would have network access and be able to snoop traffic or play man-in-the-middle, in addition to looking at host memory. Of course, with hardware access, it would always be possible read the firmware off the peripheral’s ROM. However, assuming that there is no practical way to scan the firmware from the host CPU, and assuming that reflashing the ROMrequires cooperation from the device CPU, it could be possible for the code incorporate itself into new firmware images loaded from the host. This would make it not only covert but difficult or impossible to eradicate without physical disassembly of the board.
  • Another approach involves encrypting the software and executing it on a protected hardware decryption offload device (or on a specially-modified CPU). This would allow for simple storage and loading of the software while defending against its reverse-engineering by the adversary. This does raise the question of where to store or how to securely load the decryption key, especially in a large distributed environment. Assuming that Trusted Computing hardware is available on the system, one potential solution would be to have a non-encrypted seed-loader-hypervisor that verifies its own integrity—and its execution outside of a virtual environment—that obtains the decryption key from the network using peer-to-peer or other protocols.

Both of the above approaches rely on the availability of special-purpose hardware to perform independent execution, decryption, or attestation. Requiring special-purpose hardware is technically practical, thanks to products such as the IBM 4768 secure cryptographic coprocessor card, but we anticipate that the cost-efficiency of the widespread deployment and management of the hardware will keep hardware-based solutions impractical for years to come. Our solution does not require specialized hardware and thus, at the expense of not protecting against an attacker with physical hardware access, is immediately practical.

A third example combines our approach with well-known recent work:

  • Inserting a virtualization layer between the existing virtualization layer and the hardware—the technique demonstrated by the recent Blue Pill and SubVirt work on multi-layer virtual machine monitors—would allow our covert software insertion tool to run at a level more privileged than all other software on the system. This would enable us to use the techniques developed in Task II to insert protection software anywhere, including in the VMM, a privileged VM, or an ordinary VM. To be effective such an approach would likely need to be predeployed on all systems to be monitored (i.e., every system either currently runs multiple layers of VMMs or is able to be rebooted to install another layer on demand), and would also likely employ techniques that attempt to hide the fact that the extra virtualization layer exists.

All currently-demonstrated technologies for running multiple layers of virtualization on an x86 system are highly specialized to the specific hypervisor technology deployed on the system. As these technologies are seemingly in a state of constant flux, we choose to focus this proposal on developing the techniques for the external insertion and scheduling of rogue software; once developed, these techniques may be placed and run anywhere, including in such an extra virtualization layer.

We note that our team has expertise in all three of these alternate areas. The technologies we develop under this program would certainly have relevance in any future research and development work that explores broader forms of software insertion and countermeasures to insertion.

July 9, 2008

Cyber security conference

Filed under: Reviews — JLG @ 11:48 PM

In June 2008 I attended a “Cyber Security Conference” in Arlington, Virginia.  The format was two days of invited 35-minute presentations by big names in the government and government-contractor space.  I only attended day two so I missed half the discussion.  Here are some of the major themes from today’s twelve speakers:

  • Targeted phishing (a.k.a. “spear phishing” or “whaling”—can we as a community agree to stop coming up with terrible nouns like these?) was mentioned more often by more people than any other cyber security problem.  Targeted phishing is a social engineering attack where someone learns enough about you (or your work environment) to send you a custom-made email.  One example involved a newly-promoted CFO, where the evildoers read about the CFO’s promotion in a newspaper and wrote a letter from “HR” asking (successfully) for personal information, passwords, etc., in order to set up the new executive’s computer account.  Four of the speakers mentioned phishing as one of the top problems they are facing on corporate and government networks…
  • …which reminds me how two speakers complained that spending/effort on cyber security is not well-balanced among the actual risks.  Joshua Corman of IBM phrased it nicely by pointing out that cyber attacks merely for the sake of attacking (“prestige” attacks) ended in 2004; attacks since then appear to have been driven either by financial (“profit”) or, more recently, activist (“political”) motives.  The problem is that the bulk of cyber security efforts/dollars are going to thwart attackers that are easy to identify (worms, spam) leaving us exposed to more discreet attackers.  (Of course, nobody had a ready solution for how to identify and thwart these discreet attackers—a discrete problem.)
  • However, two speakers independently mentioned anomaly detection as an it-continues-to-be-promising approach to cyber security, while acknowledging that the false positive problem continues to plague real-world systems.  One of the core problems I’d like to see studied involves the characterization of real-world network traffic (especially in military environments).  Specifically, for how long after training does an anomaly detection model remain valid in an operational system: seconds? hours? weeks?

Two talks I really enjoyed were from Boeing and Lockheed-Martin, in which a speaker from each talked about the organization and internal defense strategy (applied cyber security?) of his corporate network.  I appreciate when companies are willing to share these kinds of operational details to make reseachers’ jobs easier: storage companies take note!  Unfortunately the talks were light on details but provided some interesting insight on email defense (#1: Outlook helpfully hides the domain name, aiding a phisher’s task, so write filters to block addresses like “jaggedtechno1ogy.com” at the corporate mail server; #2: many spams or phishing attacks come from newly-created domains, so write filters for this too—I’ve mentioned previously that we should perhaps tolerate some inconvenience for the sake of computer defense, and these are good examples of that).  Two questions I’d like someone to answer:

  1. How can we coax corporate network managers to be willing to evaluate active response systems (e.g., attack the attacker) on production networks?  It is probably much easier to do there (legally) than on government networks.
  2. When will corporate networks deploy the security support services (admission control, identity verification, key management) that allow application programmers to focus on their core competencies instead of being security experts?  C’mon, folks, it’s 2008.

UPDATE:

Three people have mentioned that question #1 is unlikely to have an answer:

What are the corresponding real-world analogies?  When is it legal for me, personally, to respond to a physical threat?  Only when there is serious threat of harm to myself or someone else (or, in some states, my property). Otherwise, call the policy (or the military). I doubt cyber-society will act much different. But, this does beg the question of where are the cyberpolicy and cyberDoD!

And everyone agrees that question #2 needs to happen, like, yesterday:

I think that the best answer as to why it hasn’t happened is related to cost. And, in this case, cost is directly related to usability for the sysadmins. If they can do username / password and be done with it, then they will. And they will only move to other measures if/when they are required to (e.g., corporate policy, liability concerns, etc). However, if one could find a way to overlay this security goodness onto an existing network in a way that is no harder (and perhaps even easier) than username / passwords, then they might want to do it. Esp if this overlay then allowed for a tangible benefit in terms of increased security of everything else.

Thanks, Greg and Bryan.

PDL visit day

Filed under: Reviews — JLG @ 11:17 PM

In May 2008 I attended the PDL Spring Industry Visit Day in Pittsburgh, a workshop of sorts where students display their work in poster and demo form, industry visitors catch up with their old storage acquaintances, and everybody gets together for German food and beer afterward. (What’s not to like?)

Here are some of the larger tidbits I took away from the event:

1. Filesystems statistics survey

Garth Gibson organized a 5-year DoE institute, the Petascale Data Storage Institute, to explore issues of interest to folks like the national labs. A nifty thing they’re doing is putting together public repositories of useful data for storage researchers. For example, the Computer Failure Data Repository contains the data Garth and Bianca used for the MTTF FAST paper.

So, the latest one is the “filesystem statistics survey.” There is a tool that anyone can run and a respository for folks to upload their results. The type of results that they’ve generated so far are:

  • In archival file systems (at the national labs), most space is consumed by a small number of large files: 90% of space is consumed by files 32MB or greater in size, whereas 90% of files are smaller than 32MB.
  • In 75% of the archival file systems, 80%-90% of the files consume less than 2KB apiece.

This is available at:
http://www.pdsi-scidac.org/fsstats/index.html

2. Hadoop

I hadn’t heard about Hadoop before today (do I live under a rock? does everyone know what this is?) Hadoop is an open-source implementation of MapReduce — i.e., a toolset to help a user easily fire off map() and reduce() functions on his or her own cluster of heterogeneous boxes. An example from my favorite online encyclopedia: “The New York Times used 100 Amazon EC2 instances and a Hadoop application to process 4TB of raw image TIFF data (stored in S3) into 1.1 million finished PDFs in the space of 24 hours at a computation cost of just $240.”

So I guess distributed computing is just getting easier and easier. One of my colleagues was setting up a Condor cluster just as I was leaving CMU so I didn’t get to learn a lot about it or see it in action. If you have experience with Condor or Hadoop I’d appreciate your giving me an overview sometime.

My favorite Hadoop-related project was applying the “fingerpointing” techinque (from Priya Narasimhan and her students) to identify in real time which nodes are the source of performance slowdowns in a Hadoop-based system. Fingerpointing is their take on failure detection and root-cause analysis in distributed systems, described here:
http://www.ece.cmu.edu/~fingerpointing/

One of the topics I care about (related to #1) is using what auditable information has been collected about a system to actually do some useful auditing, which is why I’m interested in this particular work.

3. Home media storage

My favorite of the projects is “Perspective”, described here:
http://www.pdl.cmu.edu/HomeStorage/

They are looking at information stored in home media environments and asking questions about how real users want to interact with their storage: how easy is it to accomplish tasks such as “make sure a movie is on Randal’s ipod before he leaves for his upcoming trip” or “make sure this set of files in Zach’s JPEG archive can’t be viewed by anyone else in his household.”

User studies in computer science is an underdeveloped field. I got really interested in this after I saw some interesting work at IBM (the Sparcle project, linked below) that did a user study to see how well computer-literate people were able to specify access control policies. A lot of CS work suffers from a lack of user-centric design, so I’m happy to see any work that tries to address the problem. Sparcle is here: http://domino.research.ibm.com/comm/research_projects.nsf/pages/sparcle.index.html

« Newer Posts