all bits considered data to information to knowledge


Securing SVN external access

If you are going to allow external access to your SVN installation there are few basic things that you might want to ponder that are security related, all revolving around authorization and authentication.

1. Apply "least privilege" rule to selecting accounts, and disable unused features

If setting your SVN on Windows pay closer attention to the accounts under which processes will run.
If you do not plan implement any hooks, you can run subversion on Local System Account. Same type of account could be used with Apache server.

Additionally, secure Apache server by following all the standard procedures: disabling all unnecessary modules, turning off multiple options etc.

2. Choose your access protocols wisely
There are several protocols that can be used to access SVN:
[irrelevant, by and large]
file:// - Through this protocol you get direct repository access. Works only on the same system (local disk), not over the network.

[not secure]
http:// - It is possible to use WebDAV on a Subversion-aware Apache2 server to access a repository. Works over the network (port 80).
svn:// - Access to a repository is done through an svnserve server. Works over the network (port 3690).

[the only ones that should be considered for external access]
svn+ssh:// - Same as svn://, but through an SSH tunnel (port 22).
https:// - Same as http://, but over a secure SSL connection (port 443).

Using reverse proxy/gateway to fine-tune the access is highly recommended
The communications must encrypted either with SSL (get a real Verisign/Thawte certificate, or generate your own), or using SSH keys (instead of passwords set in open text! It does add to maintenance but is worth it ).

3. Restrict directory browsing.

You can limit the user to the one and only one directory by disabling directory browsing altogether on Apache HTTP Server level. This comes in handy when using "blanket" LDAP authentication as it might be possible to traverse directory structure by doctoring URL

Here's an example:
# Disallow browsing
<DirectoryMatch "^/.*/\.svn/">
Order deny,allow
Deny from all

4. Test your installation for vulnerabilities: what you don't know will hurt you

To test SVN security we could use any of network security tools such as Nessus or free OpenVAS
P.S.   SVN (also: TortoiseSVN client) supports SASL (Simple Authentication and Security Layer). It adds generic authentication and encryption capabilities to any network protocol. More information can be found here


Who mines the miners?

Organizations like to keep their cards close to the chest.  For a long time BI/analytics was all in-house affair: tools, skills and - especially! - data. The shift towards distributed computing models such SaaS and PaaS change everything.

The data needed for analysis might not be owned by the company; it might live - virtually - anywhere: public domain, subscription service, social networks such as Facebook, geographical data from Google Maps or Microsoft Earth. This is the secret ingredient for the analysis, and just as every true secret it hides in plain sight.

SAP has announced that its flagship analytics BI - Business Objects 4.1 - will have even tighter integration with Google Maps API, going beyond location services…

One can’t help but wonder  what data Google gets to keep for its own analytic endeavors as it tracks each call to its services.  Could it be that the corporate secrets are leaking out through usage patterns?


Flies catching: honey vs. alternatives

It appears that Adobe may surpass Microsoft as primary target of target for the hackers, at least according to predictions by McAfee Labs.

I never bought the idea that a sheer number of vulnerabilities discovered in Microsoft software is somehow a proof of the inferior quality of the products, rather it s a proof of its immense popularity and ubiquitous-ness, with a promise of a bigger payoff for a hacker in case of a successful attack... [ this is not to excuse Microsoft's arrogance (Vista, of the most recent examples) and sloppiness (Windows 9x, COM and other commercially successful though half-baked technologies) but only give a credit where it's due ]

It would be interesting to compare bugs-to-market share ratios for the most popular software. Mac, despite being a Unix derivative, has its fair share of bugs; so does Linux... these numbers are dwarfed by Windows-specific threats, of course. In my experience, the more user-oriented the software is the more vulnerable it becomes as businesses do not want to alienate/overwhelm their customers with annoying warnings and tedious configuration tasks...which are necessary for strong security. Catch 22, sort of...


No application is an island II

I was cleaning my garage the other day, and came across pile of floppy disks purporting to be Microsoft Word 6.0... The high-density 1.44MB 3.5" floppies, mind you, not the old 5.25" ones with puny 720KB...

There were days, not so long ago when a person's computer was his castle. Nothing was going in unless he put it in. Neither application, nor operating system were trying to dump thousands of mysterious "patches", "updates", "fix packs" on the unsuspecting computer... Nowadays, connectivity is a given; moreover, it is required (ever tried to activate Windows by phone?). Are we better off because of it?  Do you really know what's going on on your machine at any given time? There is entire cottage industry that sprung up to help us with this mess but... "who guards the guardians"?

No, there is no turning back. We live in a brave new world. Ever braver, ever newer. It appears that Pandora box was but a Russian Matryoshka - a nested doll...

If I am to to pinpoint a single major transformation occured on my watch (so far), it would be this ubiquitous connectivity. We are always "plugged-in" - cell phones, iPods, computers... Homo Connectus, pardon my Latin.