Mocking, Set Based Development, TDD and Configuration Management
I just recently had a co-worker ask me about how I managed some of the dev projects I led. Since I'm hopelessly busy these days, I pointed him toward a posting I made in the
Lean Development Yahoo! Group a couple years back. I also discovered that this posting was mentioned in a recent presentation by
Mary Poppendieck, author of
Lean Software Development. I classify her text "Highly Recommended." It's up on my bookshelf next to Dave Astel's
Test Driven Development : A Practical Guide. Both books are available from Amazon.Com and I think might be available at
O'Reilly's Safari Site.
Here's the replay of my posting at the Lean Development Yahoo! Group.
So reading the recent discussion about set based development made me
realize I've had a couple of ideas kicking around inside my head for a
while. I thought I would lay them out here and see if anyone knows of
anything similar.
A couple years ago, I was the manager of secure product development at
Borland/ Visigenic/Inprise. All of my time was spent managing the
CORBASec level 2, Gatekeeper, and IIOP over SSL products. I'm very
proud of my teams achivements; we all worked very hard, and more
importantly, we all worked relatively smartly.
The main product, the CORBASec Level 2 Security Service for C++ and
Java, was an add-on to our main ORB product. This introduced a very
large challenge: how do we make an add-on to a product that isn't
developed yet. Conventional wisdom would tell us to develop a
specification, cast it in stone, and then have the two teams (the main
ORB team and the security team) work independently until both are
finished, then integrate the two. And to complicate matters further,
the CORBA and J2EE specs were in flux while we were developing our
product, so clearly the "maginot line" defense against change
methodology wasn't going to work for us.
This didn't sit well with any of us. While CORBA is a well defined
specification, our implementation did a lot of very interesting things
under the hood to increase performance. A lot of the under the hood
things were in flux, and it was at that level that we had to interface
our product.
So this was before the eXtreme programming books had come out, but we
had glommed onto Demarco's Peopleware as a development bible. We had a
lot of great guys that really grokked the concepts of what would
eventually be called eXtreme. We did pair programming, test-first, and
made many mockups.
Our experience there and at a few other projects after let me to
recommend a test-first, mocking development methodology that has a lot
of parallels with the Lean Set-Based Development concepts.
In the methodology, we have a kick-off meeting with software and
system architects. We identify what the major components are likely to
be. Our lead software engineer goes off to setup the CVS repository
and usually downloads the latest version of JUnit. (lately we've been
setting up a Squeak project space and making sure we're using the
latest version of SUnit, but that's a different story.) While that's
happening, the architects are talking with user reps, developing user
stories. We'll use java or Smalltalk GUIs to demonstrate concepts,
even if it's going to be a WebApp we use Swing or Smalltalk GUIs. Our
idea is to eliminate complications such as web server serving issues
or web browser HTML display issues. But getting back to the main
story... We've developed a number of stock objects to represent things
like users, tasks, email accounts, documents, etc. They're more than
just data structures, they handle things like user management, generic
document and task flow, etc. i.e. - they're real objects.
Since it takes our lead Software Engineer about three minutes to setup
CVS and get the latest version of JUnit, he'll usually come in and
join us in discussions with customers or customer advocates, sometimes
extending our base objects right there in front of the customer to
illustrate a point.
At the end of the day we tend to have an idea for what the customer
wants and can start building a firm top level architectural
decomposition of the solution. From this, major pieces of software
functionality pour out, and we can start thinking about how we'll
implement some user stories. Sometimes we use cards (a la XP,) and
sometimes we're just lazy and email each other. But we very quickly
have basic use cases (or user stories), an architectural
decomposition, and a high-level idea for how things will be
implemented.
This is where the fun begins. A lot of times we don't have firm
commitment for things like database, J2EE container (if it's a web
app), message transport options, etc. So to get started we build
mockups for such things. The idea here is that we'll populate the
deliverable system with mockups and use that to demonstrate progress
to the customer. The mockups follow use cases agree'd upon by the
customer, and are used to build our junit and httpunit tests. We
follow an iterative plan where the customer gets to see the latest
build at any time, and have a quick review two or three times a week.
Okay... here's where the set based development stuff comes in.
At early points in development, we tend to have very little idea what
technology we'll be using to implement the solution. Many times we
don't even know if it's going to be a web- app or a simple Java GUI
(or a Symbian mobile GUI or a windows client or a ... ) This tends to
be the first place we make a split and start developing multiple
solutions. We implement core functionality as model objects. The model
objects live in a VM where things like transaction management, UI
interaction, document management, et c. all are abstracted behind
pluggable interfaces. Want to use Oracle? add this JAR to the
path. Want to use Prevayler? add this other JAR to the path. Want to
use Hibernate? here's a different jar. That's a somewhat simplistic
example, but it's always the first "split" in developing our sets. As
time goes on, we identify multiple modes of user interaction, and many
times the customer will be unsure how to proceed. Usually this is
where the application buts up against a business process that isn't
well defined (some business processes aren't well defined for good
reason, so saying something like "let's nail down this process before
we move forward" frequently doesn't work on our customers.) This is
the second layer of "splits" in our sets.
For a typical project, we'll have three or four "axes" upon which the
application can move. The first is the technology axis. The customer
will ask things like "I'd like to see how this works under Oracle." or
"I'd like to see if we can send messages over email rather than paying
for TIBCO or MQ Series." The second axis is usually the "role
management" axis. Business processes tend to give different rights and
responsibilities to different roles, so we see this early in
development. The first cut of the application will ignore user role
until we get a clearer definition of who has what
responsibility. While one developer is working on what's in the app,
we get another developer and/or the PM to go over who should be
allowed to do what in the various use cases. We really like to
integrate this early in the game so we can get developers thinking
about roles and users early, but if there's a lot of confusion in the
business process about who's allowed to do what, we'll keep them
separate. The third axis will be integration with outside systems. We
like to start development with typical information flows and simply
use a mockup of external systems.
Half way through a typical development project we'll have an
application that has three or four options on the technology axis, two
on the role management access, and at least two options on the
external systems axis. We combine one option per axis with our core
application components to get a system that can be tested and
demoed. We can find integration issues very early; we'll bring the
issues to the customer and explain how they affect schedule and cost
risks. The customer then drives which options we'll eventually work
with.
One thing I've learned from hard experience is that we'll do most of
our development with a tool like Prevayler for our object persistence
component. (actually we just recently changed to using
Prevayler. Before it, we would simply read an object tree when the
application started and write an object tree on exit and hope that we
didn't crash, losing all our updates.) Most of our customers are
really married to their databases, so we haven't been able to ship a
product that uses Prevayler. The benefit this offers is our
application developers can concentrate on the business model object
and ignore problems with Hibernate or Toplink until the time that we
know our model is much firmer.
So what happens is we tend to have three or four main distinct
versions of the application that are "current." If there's a fair
amount of confusion about what the application is supposed to do,
we'll sometimes have as many as eight concurrent versions of the
app. We tend to show the customer the version that's most easily
changed, and the other versions are for people working with specific
technology options.
We've been surprised by how small the incremental cost is, though. The
vast majority of our development time is on core components that are
common to all current versions of the application under
development. At the beginning of the development project, 90% of our
engineering efforts are focused on the core components and a single
UI. As customer requirements start to be discussed, this will go down
a little bit, but will only fall below 50% if there are a lot of UI
options. The cost of doing things this way can be thought of as paying
now to avoid delays later.
We also discovered that many options that would lead to large numbers
of options are eliminated early in the development project. So, if
you're really frightened of set based development, keep in mind that
the ramifications of having a lot of different dimensions are probably
not as bad as you might think. In our case, our role management axis
goes away somewhere before the middle of our development effort. Our
technology axes will also whittle down to a small number of options
somewhat quickly.
The largest problem we've encountered is configuration
management. Keeping it straight exactly which version of which jar
we're using to implement exactly which feature on which axis can be
daunting. To address this, a large part of our iteration planning
documents talk about which features will be mocked and which will be
real on which iteration.
In my copious free time, I'm even working on a Java class loader that
knows how to read an XML file defining which features are mockups and
which are "real" and make a decision at load-time as to which version
of which java class file should be loaded. It's probably overkill, but
who knows...
No DL or RSA In Suite B?
If you're a student of cryptography as I am, there are a certain class of April fools messages you start expecting on various crypto-related mailing lists. In general they announce things like "RSA Broken, Online Banking In Tatters!" or maybe "Government Admits : DES Was a Bad Joke." Some are annoying, but some are real gems. My favorite is
one from several years back that suggests modern theories on quantum physics led the Soviets to a practical technique to break RSA. (Go ahead and read it, it's a hoot.)
Many of the attacks announced are by people with questionable motives or from people without a firm grasp of the math behind crypto (or both.) Some of my favorite in this class are people who have determined that since you can recover two 32 bit primes from a 64 bit RSA modulus and decryption exponent in a tractable amount of time, it must only take 16 times as long to for a 1024 bit RSA key (or only 32 times as long for a 2048 bit RSA key.) We've been attacking RSA for several years, but it seems to have held up pretty good. Dan Boneh published a very nice summary of attacks on RSA in 1999 titled
Twenty Years of Attacks on the RSA Cryptosystem. It also is a very good read (even if you're not a cryptographer.)
But a couple years ago I started wondering, what would I do if I happened upon a practical attack on RSA? I haven't, by the way, but after spending the time to learn about linear and differential cryptanalysis and reading analyses of algorithms in the
Journal of the IACR and various papers in the
IACR ePrint Archive, I felt I had an idea for how someone could go about finding such an attack. It seemed less like a fantasy; simply a very, very difficult problem in mathematics.
As I started to think about it, I realized that the impact of a practical attack on RSA would be tremendous and terrible. Thousands (if not Millions) of people use RSA as part of SSL endpoint authentication schemes every day to protect banking and credit card account access. Sure, people have found problems with the way X.509 certs are requested and deployed, but the problems there tend to be more on the administrative side, not the technology side. Imagine how much worse things would be if in addition to wondering whether GeoTrust actually checks someone's identity, you have to wonder whether someone's hacked GeoTrust's root signing keys.
If someone found a new attack on RSA that could compromise the existing X.509 hierarchies managed by Verisign, et al. it would throw some parts of the online world into complete disarray. I mean seriously... I've become quite addicted to online access to my bank and credit card accounts. I'm not sure how I would cope with having to call up the bank to ask whether a particular check had cleared.
So I vowed, if I ever found an credible attack like this, I would very quietly demonstrate it to financial and government representatives. Okay... maybe not the government, for all I know they would send me to camp X-ray. But I would strongly encourage the move towards some other algorithm like El Gamal, DSA, DH, ECC, etc. When most people had moved over, then I would announce my findings to my peers.
I was asked by a friend in the commercial world recently whether or not the commercial world should take note of the NSA's new
Suite B Cryptography specification. "Suite B" is a set of algorithms that have received the NSA's stamp of approval for classified government secrets (you know.. that whole SECRET and TOP SECRET thing.) NIST also approved these same algorithms for "sensitive but non-classified" information that non-military government actors frequently come in contact with. So basically you've got a government-wide set of algorithms that are approved for all sorts of things. The question from my friend was... if it's good for the government and the military, should commercial entities consider it as well?
My first response was, "I'm sure it's fine." But as I dug a little deeper I noticed that there was a conspicuous lack of "discrete log" related algorithms. Diffie-Hellman wasn't on the list. NIST's Digital Signature Algorithm wasn't on the list. RSA, which is really based on the hardness of the RSA-Inversion, wasn't on the list. This got me thinking... What does the NSA know about DH, DSA and RSA that the rest of us don't?
It could be nothing.
"Suite B" is chock-full of Elliptic Curve algorithms. ECC has a number of interesting features that make it a good fit for certain types of applications. I've often thought that the main reason we haven't seen movement to ECC
en masse is that to do ECC efficiently, you have to use some intellectual property that's still covered by
Certicom's patent portfolio. In the interest of full disclosure I should probably also point out that I'm a former Certicom employee and I still have a few shares of Certicom stock tucked away under a pillow.
The NSA recently inked a deal with Certicom that allows the US government to use their intellectual property royalty-free (of course they paid several million dollars for this right, so you might want to think of is as the US Government prepaying a fixed royalty.) So maybe that's why they're pushing ECC in Suite B. Mathematicians will sometimes bicker about it, but for the most part they agree it's a little easier to "prove" the security of the ECC algorithms than the RSA algorithm. This doesn't mean that RSA is insecure, it means that our understanding of math is such that it seems easier to "prove" the relationship between the difficulty of cracking ECC and the difficulty of known "hard problems" than a similar relationship involving RSA.
None of this means that RSA has been cracked. It simply means that the NSA's current behavior in eschewing algorithms based on DL, DH and RSA Inversion is indistinguishable from the behavior one might expect from them should they be in possession of a practical attack.
Making Safari Safe
So it's been a sad week for MacOS X security. First we had news of the
OSX/LEAP-A Trojan Horse followed almost immediately by the
OSX.Inqtana.A worm. I generally take all threats to my platform seriously, but I wasn't especially worried about either of these two.
The LEAP-A trojan appears in the form of a file purporting to be screenshots of the next rev. of the OS and requires you to enter your Admin password. I'm smart enough not to enter my administrator password just to view screenshots, and I'm willing to bet that a lot of Mac users out there would notice something fishy about the request as well. The Inqtana worm isn't causing me to lose sleep either because it exploits a vulnerability that Apple patched months ago.
Safari's Risky BehaviorBut the latest vulnerability (does it have a name yet?) has given me pause for thought. Apparently what's happened is there's a bug in the way Safari handles "safe" files in Zip archives it downloads from the Internet. Crafty hackers can use this bug to get your poor defenseless little browser to run off and do terrible things, and all you have to do is visit their web page. If you want to give it a try, you can click on the link below to see if your OS is vulnerable. If so, it will simply open another link to this story.
Don't click on this link unless you want me to run code on your system. If you don't know what this means, don't click on the link.
Okay... now that you've clicked on the link, I can tell you that you probably shouldn't have done that. You probably don't know who I am or what my motivation might be... There's not telling what
I could have done. But I'm a "white hat" when it comes to computer security, so I didn't do anything unseemly.
More InformationIf you're interested in getting a little more detailed info about the vulnerability, you can visit
Michael Lehn's page; he's the guy who discovered the vulnerability. (It's also available in german
here.)
SANS has a wonderful description of the vulnerability at their
Handler's Diary pages.
Risk MitigationYou might be wondering... what can I do to protect myself?
Well, there are three things: Unset the
open "safe" files after downloading option in the preferences, move the location of the Terminal.app and stop using an administrative account (if you can.)
The first is the easiest and you should probably do it right now. If you're reading this text in Safari, unclick the option in Safari's general preferences panel that says "
open "safe" files after downloading." Here's a screen capture of what the panel looks like *after* you uncheck this option. Your general preferences panel should look like this after you're finished.
In order for this exploit to work, the Terminal application has to be in it's default location at
/Applications/Utilities/Terminal.app. If it's not there, you should be relatively safe. You might want to move the terminal application to the
/Applications directory directly. This will, in theory, confuse the attacking script enough to make it impossible for it to run. But other, legitimate system programs also use the Terminal application. Moving it might confuse your system, so this might be an option only if you know you don't use it or you're willing to risk a tiny bit of instability until Apple releases a patch.
The third step in the mitigation plan is to stop using an administrative account. If you launch the
System Preferences application and click on the
Accounts section, you should see a list of accounts on your system. Here's a picture of what mine looks like.
If you look very carefully under my name there's the word "
Admin." If you've got one of these under your name, you may want to consider creating a non-administrative account for your web browsing. I was able to find a perfectly reasonable description of how to do this in the "Mac Help" application for searching for the string "Adding a new user account to your computer". If you go this route, I recommend activating fast user switching. You can activate this option by clicking on the "Login Options" button-like feature at the bottom of the account list on the Accounts panel in System Preferences.
Finally... research has shown that Camino, Firefox and Thunderbird are
not vulnerable to this exploit. You may want to consider using them until a patch is made available that plugs this hole. More information can be found at
http://www.mozilla.com/firefox/
What Does It Mean To "Trust" a Certificate?
I happened to catch mi amigo Kurt's presentation at the
RSA Data Security Conference recently at the
dirty little secrets of Identity and Access Management. Great talk. They were selling MP3's of the conference sessions on-site, so I wouldn't be terribly surprised to find them available online somewhere soon.
One topic that was briefly hit on during the talk was the subject of how terribly ineffective our technology can be if not married to the right policies and procedures. Case in point... Brian Krebs most excellent blog over at the Washington Post recently posted a story about Identity Management gone terribly wrong. In the story,
The New Face of Phishing Mr. Krebs describes a rather fundamental failure of one of the most trusted aspects of ID on the 'net: the SSL Server issuing process.
No doubt many people reading this will never have requested a SSL certificate (SSL being Secure Sockets Layer, one of the more popular methods for encrypting your credit card number as it goes from your browser to the shameless commerce division of your favorite site.) Web servers that use the SSL protocol must first receive a "server certificate." The reason is pretty straight-forward; it doesn't matter if the link is encrypted if a bad guy can fool you into talking to their site instead of your bank. Like a drivers' license, a site's server certificate provides a level of proof that when you point your browser to amazon.com, you're really talking to amazon.com and not some criminal enterprise that's made a site that looks like amazon.com in an effort to steal your credit card number.
But server certificates don't come from the local DMV; they come from a number of private companies who get a relatively hefty fee for providing the certificate. In theory they're supposed to investigate the identity of an applicant, but many outsource this process to others. Last year the company I worked for needed a "code signing certificate" from
VeriSign. It would have been a bit difficult for us to fly to their offices in California with our Washington DC drivers licenses, so after checking us out in the
Dun and Bradstreet database, we were referred to a local notary who took a close look at our IDs to ensure we really were who we said we were, and if I remember correctly we had to show up with a bank statement and some letterhead.
The dirty little secret of SSL identity management is... it's possible to hack all these forms of ID. It's expensive, but it's possible.
And this brings me to one of the most frequently misunderstood concepts in information security. "Computer Security" is seldom absolute. The words "Security" and "Trust" have to do with the processes you put in place to defend your sensitive data against attackers. "Secure" means you don't do risky things, and "Trusted" usually means that you do some risky things, but the tools that do risky things have been examined by very smart people and we think they're hard to subvert.
Just having a virus scanner or a copy of PGP on your PC isn't going to make it more secure (or trustworthy.) Using a virus scanner as part of a daily (or hourly) check of your system will help you out. Using PGP to religiously encrypt your emails will also help enhance your security (though it might limit who will get email from you...)
But getting back to the story on Brian Kreb's Washington Post security blog...
In the case described there, it looks like some bad guys registered the domain mountain-america.com. That's easy... anyone can do this; all you need is a credit card. But the interesting part is they were able to convince SSL certificate issuer
GeoTrust to issue them a certificate. This is a little harder, but not terribly difficult to do. Though the exact requirements are shrouded in mystery, you can probably get one of these with a credit card and a bank statement.
If anyone asked, I'm sure the bad guys said they were some legitimate business getting ready to peddle olympic memorabilia. This is the dirty little secret we rediscovered this week. There's nothing embedded in the Internet to verify that a particular site is run by
Mountain America (the credit union) or
Mountain America (the information resource for Las Vegas and Travel) or Mountain America (the phishing scammer.)
Having a server certificate that says you're mountain-america.com doesn't mean you're Mountain America (the credit union), it means that somebody went through a due diligence process to ensure that there's a working email account at mountain-america.com and that somewhere out there, there's probably a "Doing Business As" filed in Utah for a fraudulent company with the words "mountain" and "america" in the name.
In the computer security world, we like to talk about "trust" being built into certificates. But that "trust" is not in the assertion (that mountain-america.com is a credit union) but that someone reasonable (the certificate issuer) took a look at someone else's ID and decided to believe it. In this particular case, we found out that they were duped.
Tags:
ssl,
x.509,
ssl,
certificate authority
Abstraction in Software : Open Implementation
So I've been sort of pulling my hair out with C++ for the last couple months. I really wish I had something more Smalltalk-like or Self-like to work with on a daily basis. I was recently trying to explain to a co-worker
why I liked Self a bit more than C++. No... I don't want to get into a religious debate here. As has been said in the
Tao of Programming by Geoffrey James:
The Tao gave birth to machine language. Machine language gave birth to the assembler.
The assembler gave birth to the compiler. Now there are ten thousand languages.
Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.
But do not program in COBOL if you can avoid it.
To be sure there are many reasons why Smalltalk can be a poor choice for an implementation language (performance isn't one of them, btw.) But one thing that Self and modern Smalltalks seem to do right is they tend to provide developers with all the tools they need to express meta-object protocol and thus create a "rich" interaction between client and service.
It's a pretty difficult concept to put across sometimes, so I was especially happy to discover some guys at
PARC came up with name for it:
Open Implementation. If I were to summarize OI in a paragraph, it would probably go something like this:
Developing working software system is a complicated exercise usually involving multiple engineers. As systems increase in capability and complexity, the ability of any one individual to understand the system decreases. In order to "get a handle" on complexity, we use abstraction and decomposition manage the details of how components interact with one another. It's typical of this traditional "black box" technique for an application programmers interface to be provided for clients and the client's developer encouraged to "ignore the implementation details". But we still have systemic problems with performance, security, robustness and quality. Why? Because by focusing on a static interface between client and service we encourage the client to use the service without an understanding of side-effects of the implementation decisions. Open Implementation (and later AOP) sought to understand the affects of this "impedence mismatch" between service and client programmers.
If you're an Aspect Oriented Programming afficinado, then there's probably nothing new in OI. But if you've heard of neither, you might want to look at OI before looking at AOP. I found the OI pages at PARC to be well reasoned and presented; something I wish was the case with the efforts I've seen to present AOP. Another way to put this... After reading the OI pages, it's clear that the last AOP paper I read assumed the reader had read the OI material first.
Tags:
oo,
aop,
open implementation,
programming
866 660 6940 : Phishing Call?
So I just got a call from (866) 660-6940 on my mobile phone.
On the other side of a surprisingly garbled connection a woman was saying something about "mpthhg mhmmrmg group." I had been expecting an insurance quote from a broker, so I asked a couple times for her to repeat.
Eventually I figured out she was not calling to provide me with an insurance quote, but was looking for a business called "the national group" and asked if this was a business phone number. She gave me my number and I verified that she had dialed correctly but told her that she had reached the wrong number; in fact she had received my mobile phone number. After that she politely apologized and hung up.
I was a little curious why someone would be calling my number (which I've had for about four years) looking for a business that's clearly not me. So I did what any other geek would do, I googled the number. If you do a google search on
"866 660 6940", the number my callerID said she was calling from, you get a number of interesting hits.
Most of them detail experiences of being phone bombed by people claiming to be from the Experian credit reporting bureau, claiming to be calling to verify information for some sort of business directory.
I'm just a little wary when it comes to unsolicited callers asking for business details. Apparently so are some other people; more than a few people
received calls like this and I'm beginning to wonder if it's not
some sort of phishing scam.
Anyway... if you happen to get a call like this, my recommendation is to politely decline to divulge identifying information. Or ask for phone number and employee name and call Experian's main number from
their web site and ask for the employee by name.
Tags:
experian,
phishing,
8666606940
Guy Kawasaki on Email Etiquette
I just discovered this gem over at
Guy Kawasaki's blog:
The Effective Emailer. This is Guy's take on how to write effective emails to busy people. As many might know, Guy was an energetic participant in the early Apple mystique generating machine. So I was sort of expecting to see something groundbreaking and earth-shattering. But the article was really a reiteration of basic email etiquette and common sense which can be summarized by the statement, "If you're writing an email to someone in an effort to get information out of them or to convince them that you know what you're talking about... don't be a cork-head."
Guy probably doesn't have a lot of free time on his hands now that the SiliValley machine seems to be heating up again, so if it's getting published on his blog, it probably means he's getting a lot of email that violates the simple rules of common sense. So, it's probably worth looking at again; you'll find it on his blog at:
http://blog.guykawasaki.com/2006/02/the_effective_e.html.
Tags:
apple,
guy kawasaki,
email
Science Fiction.. or Prediction?
Mi amigo Michael just sent me a link to an article interesting article about Hyperspacial "Warp Drives" at
the New Scientist web site. In the story,
Take a leap into hyperspace, author Haiko Lietz describes a near-apocryphal branch off the main trunk of theoretical physics. A branch that if followed could lead to such concepts as Anti-Gravity and Warp-Drive.
While it's easy to be swept away into the world of fiction.. heck, I read Silicon Valley business plans just about every day! But seriously... According to our best current understanding of science, Anti-Grav and Hyperdrive are
not possible. Yes... it's hard to say something is impossible, but Science as a domain of study prefers to understand physical mechanisms and really likes to see predictions from theory that can be experimentally verified. That second part is why some experimental physicists bristle when they hear the words "String" and "Theory" used in the same sentence. "String Theory" should perhaps be "String Hypothesis," they claim (or "String Conjecture" others claim.) Why? Because as of yet no one's come up with an easy way to verify String Theory's predictions about the universe.
And this is why many scientists are dismissive of things like the warp drive. When someone says, "I have an idea for a warp drive," the properly skeptical scientist will ask, "okay... how does it work?" In science, you're supposed to take established learning or theories and produce new hypotheses. So someone with an idea for a "far out" idea needs to demonstrate a step-by-step connection from the world of our everyday experience to their fantastical ideas. Several people have come up with some interesting hypotheses, but as of yet no one's rushing out to experimentally validate the warp drive concept.
But if you step back from the lab bench for a while and try to get a broader perspective of the role of science in our understanding of the world around us, we can take a few moments to indulge our whimsical fantasies. Many technological advances were at one point or another publicly decried as impossible by established, reputable scientists. This probably has more to do with the fact that science tends to teach it's adherents to be a little skeptical and less to do with scientists being closed minded. But if you look at the history of science, it's the history of people advancing radical ideas, proposing ways to test radical ideas, and then carrying out the tests.
And this is where we stand with the so-called "Heim-Dröscher space." A theoretical curiosity, the work tends to suggest that Warp Drive and Anti-Gravity are within the reach of mortals. The article above provides a brief history of the idea and hints at the idea that it's possible to test hypotheses based on the work of a pair or somewhat obscure German physicists.
Were I a betting man, I would say it's still science fiction. But Fiction has a surprising ability to predict sometimes.
Tags:
sci-fi,
physics
But The Window Was Left Open
New Scientist is reporting on their site that while damage from the much-ballyhooed Nyxem virus appears to be minimal, the Russian Stock Exchange did not get off so easily. In the article
Computer virus fells Russian stock exchange author Will Knight reports that officials for the
Russian Trading System announced the exchange was temporarily taken offline to assess and repair damage from a partially successful attack by network thugs.
According to the article a single, unprotected system used for testing was infected with a virus giving the unknown attackers a platform to launch a DoS (Denial of Service) attack on the more sensitive operational systems run by the exchange.
Kaspersky Lab's senior technology consultant David Emm is quoted as saying it looks like a "specific hack attempt," thought the motive for the attack is unclear.
So what can we learn from this?
First, the classical picture of a virus maker as being an anti-social geek looking to prove their personal mastery of computer security is probably no longer accurate. Sure, there are probably still a lot of people out there crafting viruses for fun or to show off, but organized crime syndicates appear to have caught on to how to use computer networks to further their traditional criminal aims. In
a story on the Scob virus from a couple years back, author Adam Balkin quotes Michael Miller of PC Magazine:
"This one seems to be capturing keystrokes and they seem to be looking for passwords and things like that and sending that information to people overseas. It's really organized crime now and that's perhaps the most worrying thing here. This has, in fact, now become real crime and they're trying to do really bad things."
What we're seeing here is real criminals using computer viruses as a technique for infiltrating sensitive systems. Had the infection gone unnoticed, it's possible the infected system could have been used to launch an attack against the systems that execute stock trades. Fortunately the security mechanisms in place at the Russian Trading System worked and they were able to take actions to prevent further infection.
But this brings me to my second point. Why was a system used to test the functionality of the trading system given access to both the internal RTS computer systems as well as the internet. There's a well known doctrine in computer security called "Defense in Depth." It directs system and network architects to design computer systems with multiple interlocking security mechanisms. You're probably familiar with this concept already; many corporate and home networks are protected by a firewall which blocks certain types of attacks. But you also have to use a username and password to log-in. Why? because attacks that are not thwarted by the firewall can be diminished by a properly configured system that requires user authentication. The "depth" part of this example comes from the fact that even if an attacker was able to circumvent the firewall, they would still have to find a valid username and password pair. It doesn't guarantee the system will be impervious to attack, but it does (in theory) slow down certain types of exploits.
However, "defense in depth" is useless if you create pathways around computer security controls. The RTS network operators did this when they allowed a testing system to have access to both the internal and external systems. In the computer security world, we refer to this as "locking the front door but leaving the window wide open."
But the sad truth is that we all do it. The entire concept of a Network DMZ ("De-Militarized Zone") is that trusted computers in the DMZ have access to both internal and external networks. DMZs are used when network operators want to share sensitive resources to Internet users. Banks that provide online banking services likely use a DMZ. You as a customer are allowed to communicate with a web server in the DMZ, but not the database or application server inside the bank's intranet. The DMZ web server is allowed access to these systems. The idea is that the DMZ systems can be hardened against attack and all communication with "back end" databases would have to go through the DMZ. If there was an attack, it should show up in the access or error logs of the DMZ system. Assuming the network operators were properly monitoring their logs, they could see the attack and refer the case to appropriate legal authority.
The RTS affair is a slightly different case. I'm going to guess that the RTS exchange tests their systems in many different ways. They probably use some "internal" tests that test how individual components of the system are operating. Sometimes called "unit tests," these tests need intimate access to the trading system and should therefore be inside the corporate firewall with limited incoming and outgoing access to the internet. I mean seriously... why do you need to surf the web from a system whose sole purpose in life is to test the innards of an electronic trading system? A different type of test is the "end-to-end test." These tests simulate the experience of the user. There are plenty of reasons for performing these tests from "outside" the firewall.
But there's no reason to put both tests on the same system. And there's no reason to allow your external testing system access to internal resources.
In summary... Russian Trading System overall security controls... Good! Though they were attacked, someone noticed the attack and took steps to stop it. Allowing indiscriminate access to a privileged system... Bad! They might not have had to have suspend operations had they not allowed one of their testing systems to be "blessed" with respect to their internal network. My guess is they've learned from this experience and will be taking proper precautions in the future. My advice to the general Internet community is to learn from their mistake and make sure something similar doesn't happen to you.
Tags:
network security,
computer virus
Greek / US Officials' Phones Tapped By Persons Unknown
So it looks like news is breaking across the blogosphere about the
Phone Tapping Scandal in Greece. News articles are available at
The Seattle Post Intelligencer,
Κεντρική σελίδα [greek],
Hellenic Radio,
Athens News Agency and
Reuters. A
Dow Jones Newswire story goes on to involve Ericsson in the controversy (Ericsson provides equipment for much of Vodafone's network in Greece), though Ericsson spokesperson Peter Olofsson has said that they can find nothing wrong with their equipment in the region.
The lowdown is that someone, somewhere wanted to tap the phones of US and Greek officials, Journalists, Human Rights Activists and their family members. Software was introduced into Vodafone equipment somewhere that caused calls in and out of these numbers to be illicitly conferenced with one of fourteen pre-paid mobile phones. Technical details are sparse, but it's clear that this has been a major intrusion onto Vodafone's operations.
Members of the Greek Socialist parliamentary party have reacted angrily after learning that the opposition government kept the wiretap a secret for 10 months. Vodafone learned of the tapping malware after an internal audit prompted by subscriber complaints. Giorgos Koronias informed the government in March 2005 about the exploit.
When analyzing the security of a mobile platform, there are a couple places you want to start looking. Understanding exactly what happened is made more difficult due to the lack of known technical details. The wiretap is being reported as a problem with the Vodafone network, and not with any specific mobile handset manufacturer, so it makes sense to suspect Vodafone's systems were compromised (and not the software on any individual mobile handset.)
Though we can guess what was infected, it's still unclear how the spyware was introduced into the system. Call processing software has traditionally run atop custom "real-time" operating systems, though Unix and Microsoft Operating Systems have been gradually increasing over the years with respect to embedded performance. If the attack was made against a COTS (Commercial Off-The-Shelf) operating system, then it is a lesson for system integrators to pay closer attention to the security of the "whole system." It's simply not enough to say, "Oh... Windows is a perfectly secure OS... besides we turned SSL on." On the other hand, if the attack was successful against a custom, home-grown Ericsson operating system. Ericsson announced several years ago they would begin using software from
Green Hills Software for some products, but it is unknown if this was the operating system running on the infected device.
Software infections do not only occur in operating system code, however. Applications are known to introduce vulnerabilities that can be exploited to introduce malware into a system. It's also possible that a configuration error of two "secure" applications on a "trusted" operating system can lead to vulnerabilities. Software consumers are demanding greater functionality and flexibility in their systems leading to integrators providing solutions with "best of breed" products from a number of different manufacturers. It is occasionally the case that security controls must be degraded or eliminated in order to achieve optimal performance for collections of programs.
Ubuntu Using Expired Self-Signed Certificate
What's the one true operating system?
Gotcha! It's a trick question. There is no "one, true OS." As was written in the
Tao of Programming, "the Tao is embodied in all software -- regardless of how insignificant."
One OS I use a lot recently is
Ubuntu. It's a Linux distro based on
Debian that's focused on (among other things) desktop stability.
Ubuntu is managed by
Canonical, Ltd which was funded by Internet business tycoon
Mark Shuttleworth. Mr. Shuttleworth is famous for being an early Space Tourist and for forming
Thawte, a commercial certification authority.
This is why I thought it was so odd to find that
https://www.ubuntu.com/ is using a broken, expired, self-signed certificate. To be completely fair, however, it doesn't look like they're doing anything sensitive with this URL. Their order fulfillment system at
https://shipit.ubuntu.com/ uses a proper certificate from
ValiCert by way of
Starfield Technologies.
Still... seems a bit odd.
BTW, here's the openssl output for the cert I found at
https://www.ubuntu.com/:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
db:96:a8:8b:ec:c2:6b:ee
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=UK, ST=London, L=London, O=Canonical Ltd, OU=Canonical Ltd,
CN=Canonical Ltd/emailAddress=systems@admin.ubuntu.com
Validity
Not Before: Dec 7 13:22:01 2005 GMT
Not After : Jan 6 13:22:01 2006 GMT
Subject: C=UK, ST=London, L=London, O=Canonical Ltd, OU=Canonical Ltd,
CN=Canonical Ltd/emailAddress=systems@admin.ubuntu.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:c9:c0:80:19:72:30:bb:07:fb:15:94:74:0b:21:
6c:4c:c7:6c:d1:35:c3:0a:19:19:1d:4e:fc:8f:75:
81:95:00:36:a0:03:3f:28:ad:fd:da:5e:11:e7:13:
df:59:28:77:90:e9:cd:15:60:76:af:24:b0:1c:b0:
61:6a:3c:fe:3e:7d:81:37:6f:7f:8f:3d:4d:dd:31:
b7:ff:ae:91:71:70:83:6b:96:ca:3d:22:a9:69:e4:
fb:b0:58:c3:ac:c9:f4:f4:53:3e:5a:91:63:2c:b9:
89:12:d7:b7:0c:f3:2d:b9:a1:91:a2:d0:64:b4:9f:
96:21:97:8c:30:d1:40:55:95
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
69:88:6D:03:EB:0D:13:E3:29:13:F0:46:6A:10:7B:1B:3F:76:87:9C
X509v3 Authority Key Identifier:
keyid:69:88:6D:03:EB:0D:13:E3:29:13:F0:46:6A:10:7B:1B:3F:76:87:9C
DirName:/C=UK/ST=London/L=London/O=Canonical Ltd
/OU=Canonical Ltd/CN=Canonical Ltd/emailAddress=systems@admin.ubuntu.com
serial:DB:96:A8:8B:EC:C2:6B:EE
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
0f:9e:07:ff:f4:07:26:b4:e3:83:98:cf:31:06:f0:cd:cc:1f:
d5:62:29:26:ab:41:08:a3:a9:71:0f:4b:5e:d1:f1:3b:0b:93:
19:60:b6:b3:a4:fc:dd:4b:d9:51:c6:46:33:b7:22:0a:3c:e9:
6f:cf:55:d1:0c:bc:80:47:e7:bb:cb:d8:8f:ad:a1:5d:76:dc:
b2:02:82:a9:4e:ba:f1:5b:78:a3:e1:81:0f:5f:43:37:98:67:
11:34:d0:50:61:4f:90:aa:09:91:bc:77:32:07:9a:4e:ab:b8:
c7:f7:16:29:83:63:1f:5c:ed:9d:78:a5:1b:bf:52:4e:b2:e4:
b0:bf
Tags:
X.509,
PKI
Technorati Voting
So a couple years ago I was thinking about a simplified system for internet voting. I'm not talking about "real" voting where you want to make sure that people don't vote multiple times or that voters are really registered (or living human beings, for that matter.) I was thinking of some simple voting for blogs, CMSs systems and the like. I wanted a quick way for people to say "I agree with that posting" or "I think the poster of that comment is a crazed weasel."
I started to design a simple system where you could log in, post a link and ask people to vote "agree" or "disagree" with the contents of the page linked to. It's a simple web app, but I can be pretty lazy sometimes and I had a bunch of other projects on so I dropped the idea.
Then it hit me. I didn't need to do anything, I'd just write a quick javascript that generated a fake link that pointed off to nowheresville. Encoded in the link would be a description of the page you were voting on and whether you agreed or disagreed. Where it pointed was not as important as what was encoded in the link. Assuming that Google spiders everything, you could simply search for all pages that link to the "voting URL."
For example, lets say you were reading Will Wilkinson's
Happiness and Public Policy blog and you found something you really agree'd with like his posting on
How to objectively measure subjective feelings. You could simply post a page on your blog that linked to
http://localhost/com_happinesspolicy_how_to_objectively_measure_subjective_feelings_aye. If you disagreed you would post a link to
http://localhost/com_happinesspolicy_how_to_objectively_measure_subjective_feelings_nay. You then sit back and wait for Google to do it's magic. After a while, you would ask google something like:
link:localhost/com_happinesspolicy_how_to_objectively_measure_subjective_feelings_aye to see how many people agreed with you.
But there's a problem with this system.
First, I'm not sure that Google is going to maintain indexes for links that routinely point into never-never-land. Second, I don't think Google's '
link:' search specifier will distinguish between two different links pointing to two different pages on the same server. In other words, I'm not sure it can tell the difference between
http://localhost/com_happinesspolicy_how_to_objectively_measure_subjective_feelings_aye and
http://localhost/com_happinesspolicy_how_to_objectively_measure_subjective_feelings_nay.
So I dropped the idea.
But then I started using
Technorati tags. After a while I realized they could work in the same way. If you agreed with a particular posting, you would craft a technorati tag that included the site's name, a unique identifier for the page and whether you agreed or disagreed. We'll get to an example in just a second, because we have to talk about a minor problem with this process. Well.. okay.. it's not terribly minor, it's actually fairly major. But it's easily fixed.
When you search for a tag on Technorati, the results page does not list the total number of hits. You would need this functionality if you wanted to be able to count votes. We would have to get the good people over at Technorati to add this...
So why not take a vote? The guys over at Technorati seem pretty reasonable and I think it's a pretty easy modification. If you think this is something that would be beneficial to the internet community as a whole, simply put the following tag on one of your blog postings somewhere:
<a
href="http://technorati.com/tag/vote_net_cryptonomicon_msh_technorati_voting_aye"
rel="tag">
vote_net_cryptonomicon_msh_technorati_voting_aye
</a>
If you disagree, put the following tag on one of your blog postings somewhere:
<a
href="http://technorati.com/tag/vote_net_cryptonomicon_msh_technorati_voting_nay"
rel="tag">
vote_net_cryptonomicon_msh_technorati_voting_aye
</a>
After a while, you can click on the tag links to see if Technorati has found anyone else who's "voting with their tags" by clicking on the link to
http://technorati.com/tag/vote_net_cryptonomicon_msh_technorati_voting_aye or
http://technorati.com/tag/vote_net_cryptonomicon_msh_technorati_voting_nay.
Tags:
vote_net_cryptonomicon_msh_technorati_voting_aye,
vote_net_cryptonomicon_msh_technorati_voting_nay
