Monthly Archives: October 2016

CFP: T-SIPN Special Issue on Distributed Signal Processing for Security and Privacy in Networked Cyber-Physical Systems

Posted on by

IEEE Signal Processing Society
IEEE Transactions on Signal and Information Processing over Networks
Special Issue on Distributed Signal Processing for Security and Privacy in Networked Cyber-Physical Systems

GUEST EDITORS:

SCOPE
The focus of this special issue is on distributed information acquisition, estimation, and adaptive learning for security and privacy in the context of networked cyber-physical systems (CPSs) which are engineering systems with integrated computational and communication capabilities that interact with humans through cyber space. The CPSs have recently emerged in several practical applications of engineering importance including aerospace, industrial/manufacturing process control, multimedia networks, transportation systems, power grids, and medical systems. The CPSs typically consist of both wireless and wired sensor/agent networks with different capacity/reliability levels where the emphasis is on real-time operations, and performing distributed, secure, and optimal sensing/processing is the key concern. To satisfy these requirements of the CPSs, it is of paramount importance to design innovative “Signal Processing” tools to provide unprecedented performance and resource utilization efficiency.

A significant challenge for implementation of signal processing solutions in CPSs is the difficulty of acquiring data from geographically distributed observation nodes and storing/processing the aggregated data at the fusion center (FC). As such, there has been a recent surge of interest in development of distributed and collaborative signal processing technologies where adaptation, estimation, and/or control are performed locally and communication is limited to local neighborhoods. Distributed signal processing over networked CPSs, however, raise significant privacy and security concerns as local observations are being shared by neighboring nodes in a collaborative and iterative fashion. On one hand, applications of CPSs are severely safety critical where potential cyber and physical attacks by adversaries on signal processing modules could lead to a variety of severe consequences including customer information leakage, destruction of infrastructures, and endangering human lives. On the other hand, the need for cooperation be- tween neighboring nodes makes it imperative to prevent the disclosure of sensitive local information during distributed information fusion step. At the same time, efficient usage of available resources (communication, computation, bandwidth, and energy) is a pre-requisite for productive operation of the CPSs. To accommodate these critical aspects of CPSs, it is of great practical importance and theoretical significance to develop advanced “Secure and Privacy Preserving Distributed Signal Processing” solutions.

The spirit and wide scope of distributed signal processing in revolutionized CPSs calls for novel and innovative techniques beyond conventional approaches to provide precise guarantees on security and privacy of CPSs. The objective of this special issue is to further advance recent developments of distributed signal processing to practical aspects of CPSs for real-time processing and monitoring of the underlying system in a secure and privacy preserving manner while avoiding degradation of the processing performance and preserving the valuable resources. To provide a systematic base for future advancements of CPSs, this special issue aims to provide a research venue to investigate distributed signal processing techniques with adaptation, cooperation, and learning capabilities which are secure against cyber-attacks and protected against privacy leaks. The emphasis of this special issue is on distributed/network aspects of security and privacy in CPSs. Papers with primary emphasis on forensics and security will be redirected to IEEE Transactions on Information Forensics and Security (TIFS). Topics of interest include, but are not limited to:

  • Security and Privacy of distributed signal processing in networked CPSs.
  • Distributed and secure detection, estimation, and information fusion.
  • Security and privacy of consensus and diffusive strategies in networked systems.
  • Secure and privacy preserving distributed adaptation and learning.
  • Security and privacy of distributed sensor resource management in networked systems.
  • Distributed event-based estimation/control in networked CPSs.
  • Detection and identification of potential attacks on distributed signal processing mechanisms.
  • Application domains including but not limited to, smart grids, camera networks, multimedia network, and vehicular networks.

SUBMISSION GUIDELINES
Authors are invited to submit original research contributions by following the detailed instructions given in the “Information for Authors” page or TSIPN page. Manuscripts should be submitted via Scholar One(Manuscript Central) system. Questions about the special issue should be directed to the Guest Editors.

IMPORTANT DATES:

    • Paper submission deadline: December 15, 2016
    • Notification of the first review: March 1, 2017
    • Revised paper submission: April 15, 2017
    • Notification of the re-review: June 15, 2017
    • Minor revision deadline: August 1, 2017
    • Final notification: September 1, 2017
    • Final manuscript due: October 15, 2017

Publication: Advance posting in IEEExplore as soon as authors approve galley proofs

Expected inclusion in an issue: March 2018

Rutgers has a mobile device privacy violation strategy

Posted on by

Rutgers decided to switch everyone over to an Office 365 system for email. All “official Rutgers business” has to be conducted through our new email accounts. If you try to sync mail to your phone, you are prompted to install a Microsoft app which will manage your account. According to the Rutgers Mobile Device Management Policy we “will be prompted by a notice that states administrators will be allowed to make a number of changes to your device but the University will not utilize those features as they are beyond policy.”

I Am Not A Lawyer, but it seems a little bad to sign a contract with someone who says “oh don’t worry about those clauses, we will never use them.” So what are we agreeing to let IT admins do?

What IT cannot see:

  • Call and web history
  • Location
  • Email and text messages
  • Contacts
  • Passwords
  • Calendar
  • Camera roll

What IT can see:

  • Model
  • Serial number
  • Operating system
  • App names
  • Owner
  • Device name

So apparently what apps you have is something that your boss should know about. I suppose you can construct a reason for that, but I don’t really know why it’s anyone’s business. I can see it as being rather dangerous — who are they sharing this information with? Also, Rutgers wants to:

  • Reset your device back to manufacturer’s default settings if the device is lost or stolen.
  • Require you to have a password or PIN on the device.
  • Require you to accept terms and conditions.

Hmmm, abstract “terms and conditions.” Ok then… the features they say are out of scope (for now) are:

  • Remove all installed company-related data and business apps. Your personal data and settings aren’t removed.
  • Enable or disable the camera on your device to prevent you from taking pictures of sensitive company data.
  • Enable or disable web browsing on your device.
  • Enable or disable backup to iCloud.
  • Enable or disable document sync to iCloud.
  • Enable or disable Photo Stream to iCloud.
  • Enable or disable data roaming on your device. If data roaming is allowed, you might incur roaming charges.
  • Enable or disable voice roaming on your device. If voice roaming is allowed, you might incur roaming charges.
  • Enable or disable automatic file synchronization while in roaming mode on your device. If automatic file synchronization is allowed, you might incur roaming charges.

Seems like a lot for the dubious value of checking my work email on my phone. I guess I have some startup funds that need spending. Perhaps I can get a “just for work” device that Rutgers can snoop on as much as they like.

Subscribing to the NSF CIF Listserv

Posted on by

Want to get emails from the NSF’s CIF Program?

  • Compose an email to LISTSERV@listserv.nsf.gov
  • Leave the subject blank
  • In the body of the message, just write “SUBSCRIBE CIF-Announce Firstname Lastname” (without the quotes and replacing Firstname and Lastname with your name). Alternatively, you can subscribe anonymously by writing “SUBSCRIBE CIF-Announce ANONYMOUS” (without the quotes).
  • Send the message. You will receive a confirmation email that you have subscribed. Please read the confirmation email since you may need to respond to it.

Problems with the KDDCup99 Data Set

Posted on by

I’ve used the KDDCup99 data set in a few papers for experiments, primarily because it has a large sample size and preprocessing is not too onerous. However, I recently learned (from Rebecca Wright) that for applications to network security, this data set has been discredited as unrepresentative. The paper by John McHugh from ACM TISSEC details the charges. Essentially there was little validation done with regards to checking how representative the data set is.

Why do I bring this up? Firstly, I suppose I should stop using this data set to make claims about anomaly detection (which may be a problem for AISec coming up at the end of the month). However, it’s not clear, from a machine learning perspective, whether the claims one can make about a particular application will generalize within an application domain, given the lack of standardization of data sets even within a particular application. I could do a bunch of experiments on mixtures of Gaussians which might tell me that the convergence rate is what the theory said it should be, but validating on a variety of “non-synthetic” data sets can at least show how performance varies with data sets properties (regardless of the accuracy with respect to the application). So should I stop using the data set entirely?

Secondly, if we want to develop new models and algorithms for machine learning on security applications, we need data sets, and preferably public data sets. This is a real challenge for anyone trying to develop theoretical frameworks that don’t sound too bogus: practice could drive theory, but there is a kind of security through obscurity model in the data gathering/sharing world which makes it hard to understand what the problems are.

Linkage

Posted on by

Cheating: The List Of Things I Never Want To Hear Again. This is an almost definitive list of plagiarism/cheating excuses. I both love and loathe the idea of making students sign a pledge, but there’s that saying about a horse and water… (h/t Daniel Hsu)

This note on data journalism comes with a longer report about how to integrate data journalism into curricula. It strikes me that many statistics and CS departments are missing the boat here on creating valuable pedagogical material for improving data analytics in journalism. (h/t Meredith Broussard)

Speaking of which, ProPublica has launched version 2.0 of it’s Data Store!

Of course, data isn’t everything: The Perils of Using Technology to Solve Other People’s Problems.

DARPA just launched a podcast series, Voices from DARPA, where DARPA PMs talk about what they’re doing and what they’re interested in. The first one is on molecular synthesis. It’s more for a popular audience than a technical one, but also seems like a smart public-facing move by DARPA.

My friend Steve Severinghaus won the The Metropolitan Society of Natural Historians Photo Contest!

My friend (acquaintance?) Yvonne Lai co-authored this nice article on teaching high school math teachers and the importance of “mathematical knowledge for teaching.”

What’s the proper bibtex type for ArXiV papers?

Posted on by

I like to use @techreport, like


@techreport{ShakeriBS:16ks_dict,
author = {Z. Shakeri and W.U. Bajwa and A.D. Sarwate},
title = {Minimax Lower Bounds on Dictionary Learning for Tensor Data},
number = {arXiv:1608.02792 [cs.IT]},
month = {August},
year = {2016},
institution = {ArXiV},
url = {http://arxiv.org/abs/1608.02792},
}

but the handy-dandy ArXiv to BibTeX uses @misc (which makes it less handy-dandy, TBH):


@misc{1608.02792,
Author = {Zahra Shakeri and Waheed U. Bajwa and Anand D. Sarwate},
Title = {Minimax Lower Bounds on Dictionary Learning for Tensor Data},
Year = {2016},
Eprint = {arXiv:1608.02792},
}

I’d ask this on the TeX Stack Exchange but it seems more of a matter of taste.

Quantifying the professoriate

Posted on by

Faculty at Rutgers are unionized, and currently the union is trying to fight the university administration over their (secretive) use of Academic Analytics to rate the “scholarly productivity” of faculty and departments. For example, last year they produced a ranking of Rutgers departments (pdf). It’s so great to be reduced to a single number!

As the statistical adage goes, garbage in, garbage out, and it’s entirely unclear what AA is using to produce these numbers (although one could guess). It’s a proprietary system and the university refuses to give access to the “confidential innards” — perhaps they don’t want others to see how the sausage is made. If we take just one likely feature, impact factor, we can already see the poverty of single-index measures of productivity. Impact factor can vary widely across indexing systems: Scopus, Web of Knowledge, and Google all produce different numbers because they index different databases. At some point I went though and lumped together papers in my Google profile if they were the same result (e.g. a journal version of a conference paper) but then I was told that this is a bad idea, not because it would lower my impact factor (which it would), but because manipulating an index is bad form. If the index sucks, it’s the index-maker’s fault.

I wonder how many other universities are going through this process. Within one department the levels of “productivity” vary widely, and across disciplines the problem is only harder. The job faced by administrators is tough — how do they know where things can improve? But relying on opaque analytics is at best “statist-ism” and at worst reading entrails.