Pages

What Programming Language Should I Use to Build a Startup?

Often entrepreneurs ask me 'What technology should I build my startup on?' There is no right or wrong answer to this question. It's a decision every company makes for itself, depending on what it's trying to build and the skills of its cofounders. Nonetheless, there are a few rules that one should adhere to. We discuss them in this blog post.

Incident Response Policy

What happens in your company when a production incident occurs? Usually in a typical startup, you will see engineers running around frantically trying to resolve the problem. However, as soon as the incident is resolved, they forget about it and go back to their usual business. A good incident response policy can help bring order into chaos. We provide a sample template in this blog post.

Why Software Deadlines Never Make Sense

We discuss why software deadlines usually don't make sense.

Analyzing Front-End Performance With Just a Browser

We discuss a number of freely available online tools which can be used to analyze bottlenecks in your website.

Why Smaller Businesses Can't Ignore Security and How They Can Achieve It On a Budget

In this article, we show that security is both important and achievable for smaller companies without breaking a bank.

Monday, June 27, 2011

Celebrate your accomplishments

Often we lament what we have not achieved in life, but forget how far down the road we've travelled.
Here is a nice quote by Ray Bradbury that I like on this topic:

Americans are far more remarkable than we give ourselves credit for. We've been so busy damning ourselves for years. We've done it all, and yet we don't take credit for it.
Ray Bradbury

Tuesday, June 21, 2011

Most common Iphone passcodes (and possibly Securid passcodes)

There appeared an interesting analysis by Daniel Amitay of most common Iphone passcodes http://amitay.us/blog/files/most_common_iphone_passcodes.php

His Iphone App analyzed passcodes of the users. What he discovered wasn't surprising. Most common passcodes use easy combinations such as 1111, 1234, 0000 or users' birthdates. I would bet that similar patterns apply to SecurID passcodes many of which are also just 4 digits.

204,508 recorded passcodes, the top ten most common were:
most_common_passcodes

Thursday, June 16, 2011

What does SecurID breach mean?

Here is an interview with me that recently appeared in ComputerWorld about what the repercussions of SecurID breach are? My take on it is even though SecurID may have lost effectiveness as a 2-factor authentication, it doesn't have much impact on a regular day in a CISO's life. There are much bigger holes a typical CISO needs to address.

An analogy is that you have a house, with a fancy lock on the front door. Somebody figured out how to lockpick that lock. Do you go ahead and replace it? No, not necessarily. It's much more likely you have easier ways to get into your house, such as jumping over the fence.



From Network World:


This story appeared on Network World at
http://www.networkworld.com/news/2011/060111-cyberattacks-fuel-concerns-about-rsa.html

Cyberattacks fuel concerns about RSA SecurID breach

Lockheed Martin and L-3 were reoprtedly attacked using cloned SecurID tokens

By Jaikumar Vijayan, Computerworld
June 01, 2011 04:50 PM ET

Recent attacks against two major defense contractors are fueling concerns about the extent to which RSA's SecurID two-factor authentication technology may have been compromised in a breach the company acknowledged in March.

Lockheed Martin on Saturday said it had suffered a " significant and tenacious " cyberattack on May 21. The company, which is the largest U.S defense contractor, said it was forced to shut down remote access to deal with the attack, but maintained that no data was compromised.

Lockheed itself has offered few details about the breach. But Reuters, which first reported the intrusion last Thursday, cited unnamed sources as saying the compromise involved the use of cloned RSA SecurID tokens.

Wired on Wednesday reported that L-3 Communications was similarly attacked in April L-3 is a major supplier of communication, intelligence, surveillance and reconnaissance technology to the Department of Defense.

Wired cited an internal email that it obtained from an L-3 employee warning that the company was actively targeted by attackers using cloned SecurID tokens. It's not clear from the email whether any intruders managed to break into L-3's networks, or were detected while they were attempting to do so.

L-3 did not immediately respond to a request for comment.

The reported incidents are again stoking concerns that first surfaced in March when RSA, which is now owned by EMC , disclosed that it had been the victim of a sophisticated cyberattack.

RSA said that attackers had accessed code related to its SecurID two-factor authentication technology. While the stolen information could be used to reduce the effectiveness of SecurID, it would not enable a direct attack on SecurID customers, RSA said.

SecurID tokens are used in conjunction with passwords to deliver a second layer of authentication for system and network access. The technology is available from RSA in the form of hardware and software tokens that are capable of unique, one-time passwords every 60 seconds. More than 25,000 enterprises, many of them in the financial sector and government, currently use SecurID tokens to protect access to high-value applications and data.

RSA's refusal to publicly disclose what exactly was compromised -- combined with the attacks on Lockheed and L-3 -- are raising questions about how badly compromised SecurID really is.

"It seems like right now a lot of rumors are floating around," said Aleksandr Yampolskiy, director of security and compliance at Gilt Groupe. "If enterprises like Lockheed Martin are reporting that SecurID tokens were involved, then it's possible that some seeds plus details of the algorithm got revealed."

At this point, SecurID tokens' security is reduced to a single factor -- the pass code that users know. That makes them only as effective as regular passwords, he said.

Based on the reports suggesting that the RSA token was successfully emulated, "one can only assume that the breach of RSA leaked sufficient data to predict the number displayed by a particular token," Johannes Ullrich, CTO at SANS Institute, said in a blog post . "It may also have leaked which token was handed to what company (or user)," Ullrich said.

RSA's silence probably makes the situation appear worse than it is, said Jeremy Allen, principal consultant with Intrepidus.

Even if the RSA attackers managed to steal more information on SecurID than might have earlier been thought, they would still need to have crucial information to exploit it, Allen said. For an attacker to successfully use a cloned SecurID token, he or she would still need to know the token user's username and pass code to access a particular network service, he said.

For someone to break into Lockheed using the RSA token, the attacker would need at least one Lockheed employee's username and pass code and would have to know which services that person could access.

Others enterprises using SecurID technology need to pay attention to these breaches, analysts said. Until RSA offers more details, companies should keep a close eye on their authentication measures.

"RSA tokens are just one factor of a two-factor authentication scheme," Ullrich wrote. "You will have to enter a PIN or a password in addition to the token ID," he said.

Enterprises should be watching for attempts at guessing passwords and pass codes, he said. "Monitor for brute force attempts and lock accounts if someone attempts to brute force them," he said.

"Enterprises also need to keep an eye on any attempts to log into enterprise systems from unknown or unusual IP addresses," he said.

So far, at least two other major defense contractors have already switched from SecurID to other technologies, said Alan Paller, director of research at SANS.

"Both Raytheon and Northrop Grumman made massive changes to their remote security systems immediately upon learning what was taken" from RSA, Paller said. "A senior officer of one of those companies told me that they replaced all of their SecureID tokens with tokens from a different vendor. At the time, this seemed like overkill to some observers but it now turns out to have been prescient."

Jaikumar Vijayan covers data security and privacy issues, financial services security and e-voting for Computerworld. Follow Jaikumar on Twitter at @jaivijayan or subscribe to Jaikumar's RSS feed . His e-mail address is jvijayan@computerworld.com .

Wednesday, June 15, 2011

Finding the location of a Python module

Another obscure tidbit of information that I forgot. If you want to look at the source code of a Python module, you can find out where it is located using the __file__ variable.

>>> import iptools
>>> iptools.__file__
'/Library/Python/2.6/site-packages/iptools-0.5.0_dev-py2.6.egg/iptools/__init__.pyc'

Back to my Python days

I am writing a Splunk module for work to analyze IP addresses of possible attackers, and Splunk modules can only be written in Python.

I came across a nice module http://code.google.com/p/python-iptools/ for manipulating IP addresses. Using that module, it becomes very easy to check if a particular IP address is not in the blacklisted range:

#!/usr/bin/env python
import iptools

INTERNAL_IPS
= iptools.IpRangeList(
'127.0.0.1',
'192.168/16',
('10.0.0.1', '10.0.0.19'))
>>>print '192.168.1.2' in INTERNAL_IPS True


Wednesday, June 8, 2011

We take PCI compliance at Gilt Groupe seriously

Posted from Gilt Tech blog: http://tech.gilt.com:

PCI Poetry


Payment Card Industry
A poem by Sam Kassoumeh


PCI, oh PCI,
200 requirements we must comply.

From password settings to policies,
The time has come to rotate the keys.

Above and beyond the norm we go.
Protect the cards that is our goal.

Standing out in the ecommerce crowd,
We take the steps to make our QSA proud.

Passphrase A and passphrase B,
Will be joined in digital matrimony.

Fraudsters and hackers free or in the joint,
You can’t see our cards so sorry to disappoint.

And to the members we love so much,
Your information cannot be touched.

Your credit cards can’t be divulged,
In gilt.com you may indulge.

Tuesday, June 7, 2011

Practical scaling and sharding for Mongo

Here are some notes I took from a great talk on "Practical scaling and sharding at MongoNYC 2011 conference" by @eliothorowitz



Scaling by optimization
- schema design
- index design
- hardware configuration

Horizontal scaling
- vertical scaling is limited
- hard to scale vertically in the cloud
- scan scale wider than higher

Replica sets
- one master at any time
- programmer determines if read hits master or a slave
- easy to setup to scale reads

Not enough
- writes don't scale
- reads are out of date on slaves
- ram/data size doesn't scale

Sharding design goals
- scale linearly
- increase capacity with no downtime (one of biggest problems with relational dbs)
- transparent to the application
- low administration to add capacity


Sharding and documents
- rich documents reduce need for joins
- no joins makes sharding solvable

Basics
- choose how you partition data (that choice is very important)
- convert from single replica set to sharding with no downtime
- full feature set
- fully consistent by default


Two ways to spread data: hash-based and range-based

Range-based.
Collection is broken into chunks by range, which default to 64 mb or 100K objects.

collection users minKey { name: 'Miller' } maxKey { name : 'Nessman' } location shard2
collection users minKey { name: 'Nessman'} maxKey { name : 'Ogden'} location shard1

Choosing a shard-key
- shard key determines how data is partitioned
- hard to change
- most important performance decision.


Use case: photos
{ photo_id : ????, data: }
What's the right key?
- auto-increment
- md5(data)
- month() + md5(data)

Initial loading
- system starts with 1 chunk
- writes will hit 1 shard then move
- presplitting for initial bulk loading can dramatically improve bulk load time

Administering a cluster:
- do not wait too long to add capacity
- need capacity for normal workload + cost of moving data
- stay < 70% operational capacity