What is Application Security?

Basically, application security is the security profile of application level software and communication. So what does that mean? and what does that look like? and really, who cares?

Well, let’s start from the first question and work our way backward. Applications are becoming much more important as initial attack vectors into systems. Over the past decade or so, operating system vendors and developers have become much more conscious of the security of the systems they deliver. They’re spending much more time reviewing the code they deliver and becoming more disciplined in refining what exactly they deliver. They’re also incorporating more and more advanced cyber-security techniques into delivered operating systems everyday. In fact, Microsoft Windows, once the butt of just about every cyber-security joke told, is arguably the most secure baseline operating system on the market today - certainly much more secure than it was five years ago. As operating systems and related systems become more secure, attackers need to begin to look at other areas to exploit. More and more of these attackers are looking, today, at applications.

So who cares? Well, attackers really care. They’re really interested in finding applications that are running with open network connections, with system privileges, and with security flaws. Really, they don’t care that much about the authority the applications run with - the more the better, but any foothold is better than nothing. And since attackers care, application vendors need to care, and because the vendors care, we developers need to pay attention too.

It doesn’t look like things are going to change anytime soon in this regard either. Today, companies are beginning to be held liable for information leakage. We’ve seen lawsuits brought against companies, we’ve seen C-Level executives fired, and we’ve seen profound differences with respect to how liability for cyber-security negligence is determined today when compared to event a few years ago. The stakes are higher, and people way above our pay grade are paying attention.

Application software isn’t clearly defined, really, but we can do a little better than that. Fortunately, operating systems and network communication models have this nifty application layer that runs on top of the software delivered by infrastructure and operating system vendors. The OSI model has it, Windows has it, Linux and Unixes have it, and TCP/IP has it. So from a network communication perspective, anything that runs in the application layer is fair game for an application security analysis. HTTP, for example, is an ubiquitous application level protocol. I mean, it’s everywhere. If you ever look at a typical packet capture, it is just riddled with HTTP traffic. And applications use HTTP for just about everything today. Need RPC? use REST/JSON. Need to send information for storage? POST or PUT that information to an HTTP endpoint. Need to grab some data? go GET it from a web server. It’s absolutely everywhere. And there’s other cross-platform application protocols too, like Apache Thrift or Avro, or Google’s Protocol Buffers. In fact, from the perspective of the TCP/IP stack, if you’re above the TCP layer, you’re in application space.

Likewise, any program that runs in userland is an application too. This isn’t limited to third-party programs either. Anything from any vendor that runs above the kernel is fair game for application security reviews. On linux or windows, this includes everything from in-house enterprise applications to word processors and utilities to unix commands like ls or ssh. On mobile devices, this includes apps in Swift or Objective-C on iOS and Java or C++ on Android. It doesn’t include drivers, kernel modules, network infrastructure firmware, or anything like that.

originally published on DZone

Tailoring Express & Node.js for Microservices

Recently, I needed to begin putting together a Microservices-based system for a research project at the University of New Mexico. I've used sinatra for this kind of thing in the past, but I was interested in using node.js for this system rather than our usual Ruby stack - basically because we've begun to use ember for our front-end work, and it made some sense to unify our development languages. I looked around for a Sinatra-like replacement in the Node ecosystem, and didn't have much luck. As I'd used Express in the past, I realized that I could likely come close to what I was looking for using it to some extent, even though out-of-the-box it has a bit more power that I need. So I went ahead and created an Express project and began to strip out what I could to make it a pure microservice delivery environment rather than a web server.

Now keep in mind, Express is more like a (very) stripped down version of Rails than a system like Sinatra - which is just fine. Rails gives you quite a bit, but you don't always need everything that it supplies (at least I don't). Sinatra is very easy to use, and I really enjoy its DSL and flexibility, but you need to build a few extra things that Express will give you for free. Nevertheless, the routing model in Express is very similar to Sinatra, and it allows you to use Node's primitives to deliver data in various formats (though all I was really interested in was JSON, honestly). So it seemed like a good starting point.

First, create the application - once you've installed Express, Node, and the various dependencies, you create a simple Express application via the express command. This gives you a standard Express application layout that you can now start to tweak. First, let's start with the app module in the application root. This is referenced by the www script in the bin subdirectory called by npm when you start an express application with npm start:


Note some key changes in the app module. First, we've removed access to the /public subdirectory that usually contains various web resources like images, scripts, and HTML pages. We've also removed references to views or view engines, as we aren't providing any visual user interfaces to this system. Finally, we've added the ability to emit debug statements from the module, and we've changed the error handlers to return JSON rather than HTML views describing errors, while keeping the separation between production and debug error handling and resulting stack trace containment.

At this point, you can modify your package.json file to remove unused dependencies:


The only dependency we've removed is the view engine, Jade. Remember, we originally created this using standard CSS processing, so we didn't include a CSS pre-processor like Less.

That's it! You now have a microservice container configured with no visual engines, storage, or elements. Type npm start at the command line, and you should be ready to go.

Logging in Ruby to S3

So one of the requirements I have in my dissertation work is to provide a centralized logging location for the 20-30 VM images I use.  The VM's themselves host a system that provides overlay network functionality in either hierarchical or non-hierarchical forms in a variety of levels of granularity, and the individual nodes in the overlay networks need to report some status and other information regularly that I need to then retrieve and analyze.  Using the filesystem for this is just not workable as the logs are, first, downright hemorrhoidal to download and collate, and second, the providers I'm using like to pseudo-randomly delete transient files from your filesystem.  I decided that the easiest way to go was to use something cheap and easy like S3.  So instead of using something just like S3, I went ahead and used S3.

I also didn't want to create my own logging system, because I wasn't going to spend enough time on it to make it un-sucky.  So I decided to use logging - looks feature rich and easy to use, and nicely tested to boot.  Plus it's newer than log4r, so that's nifty too.  And I can format logging messages in YAML, which means analysis of the log messages is a breeze via the Ruby YAML gem.

Okay, so using logging, I can publish log records in YAML using a mature logging framework.  And I'd like to store these messages in S3.  So how to go about doing that?

Well, first, let's configure a really simple STDOUT logger that formats data in YAML (this is all implemented via examples from the logging distribution, I encourage you to look through the examples).


So this example formats the log entries in YAML, and also formats any saved data structures in YAML for later recreation! Pretty handy:



Some text here.  Now that we have a system that will save information in YAML, we need to send the information to S3 in some way.  In order to do that, we can add a custom appender to the logging library. Fortunately, I'm using Ruby, so this isn't as hard as it sounds.

First, let's create a simple class within the logging modules that recreates the STDOUT logging we just demonstrated.  Looking through the logging codebase, we can follow the example in console.rb by creating a factory method and implementation class.  The final example looks like this:



Now this is hardwired to emit YAML, but that's okay, that's really all I need.  Here, we create a factory method, register the implementation class, and then create a really simple class implementing the methods from the Ruby IO class that we really need (e.g. the syswrite(.) method).  With that in place, we change our logging script to use the new appender:


And we get YAML output with the new field:


Note the new field, source, something pretty important when combining log files from a bunch of different sources.

Now that I have this in place, I'll start looking at how to wire it to S3 and test it in RSpec.

Domain Driven Design, Grocery Lists, and Node.js

To begin building this grocery list system, we need to first establish some of the baseline requirements and the domain model.  First, we have npm, nvm, and the latest node environment installed.  Next, install jasmine node (this, with the latest version of npm, can be done via npm -g install jasmine-node, at least on a mac).  I'm also going to use Jake, which installs via npm as well.

Now that we have the requisite tools installed, we build the project directory.  I like to use a pretty common structure stolen from Ruby projects I've worked on in the past, with a the subdirectories bin, etc, lib, and test, with a README and a makefile of some kind at the top level of the directory structure.  The Item entity is pretty straightforward:


It defines an item with a name and a description. We may elaborate on this in the future, but it's fine for now.

Likewise, we're going to use a named collection of objects:

The idea behind this simple collection is that folks will want to name their lists, and so we've provided a way for a JavaScript array to be named. Next time, we'll go over the tests in place to exercise these objects, and we'll delve into the command line interface. Eventually, we will host this service on Heroku, and initially at least we'll access that service via the command line interface we develop.

ACM Computer & Communication Security Talk

Just got back from Chicago and ACM CCS.  Great conference - I gave a talk at the DRM 2011 workshop on Friday.  Overall, I loved Chicago! Great city, the downtown architecture was fabulous.  Ate nothing but Chicago-style food while I was there so I had a big salad when I got home.

npm, nvm, and firewalls

So I just finished going through a wonderful experience getting npm, nvm, and so on installed on a system behind a firewall at the local university.  Specifically, I was having problems with this url:

https://registry.npmjs.org/npm

Now I was using a mac, and didn't want to deal with loading all the certs I might require, so I downloaded hte install.sh file (curl http://npmjs.org/install.sh > install.sh), changed the URL to use HTTP, and it worked without a hitch.

I needed to make a similar change when installing jasmine-node, the registry in NPM is automatically set to use the HTTPS repository:

npm config set registry http://registry.npmjs.org/

Everything seemed to move smoothly after these changes.  Personally, I'm not sure we need to use HTTPS for either of these.  I suppose I could inject changes into the stream if I was evil, and using an encrypted channel helps protect from this, but I'm somewhat skeptical that this is really a big deal.

Also installed NVM; love it! I know there's other version managers for node out there, but this one's doing the trick for me.  I configure a bit differently though, using a .nvmrc file (that is in turn sourced from my .bashrc) that contains a single line:

[[ -s "$HOME/.nvm/nvm.sh" ]] && . "$HOME/.nvm/nvm.sh"

This is adopted from RVM, another great version manager.  Now that I have this out of the way, I'm going to get started on my list server.  The next posts will cover initial domain design and project repository structure.

.Net and WinRT

Well, I have to say, Microsoft is making a bold move with .Net and Windows 8. It seems like they're betting that what people use computers for has essentially been established, and it isn't what we're used to.  Basically, they're betting the company that people don't want computers they sit in front of and type on all day.  Instead, they want something smaller, something that has a tactile interface, that allows them to read email, watch movies, check bank accounts, maybe create an occasional document, and so on.  What they don't really want is what they have - workstations, notebooks, things that require a keyboard, a mouse, and an investment of time to use.

I think they're probably right in broad strokes, but the devil will be in the details.  Microsoft still makes the lion's share of their revenue from operating system and office licenses, last I checked.  It's about 60% of their revenue, in fact.  I think this is the first time they've really done something this radical in those segments.  I mean, what could compare to changing the entire way people interact with their computers? to relegating the workstation role to a small segment of their installed base? Windows 95? not even close if you ask me.

So the Windows 8 development stack is all on top of the Windows Runtime (WinRT), so apps will be developed in a typical web stack (CSS/JS/HTML) and/or in C++.  I'm personally interested in how you effectively merge the two - heavy lifting in C++ via WinRT, and integration and UI with web tech.

So what happens to .Net? Well, you'd better get familiar with Azure.  I think the writing's on the wall at this point, .Net is going to transition to being a cloud development framework, and move away from the client.  No more WPF, WinForms, or anything like that.  I suppose they'll continue to support it in desktop mode, but how many people are really going to use that?  Folks like us (developer-types) will, sure, but let's face it, there's not many of us out there.  I'll be interested to see how long desktop mode sticks around now that's it's essentially yesterday's news.

I've just downloaded the developer preview released from the Build conference. Hopefully, it'll be stable enough to work with a bit.