When you look at an IP address or even domain name in your logs – where is that person coming from? You might need to know for forensics purposes, or even “cyberwarfare” purposes. Keep in mind that spoofing an IP address isn’t rocket science, and just knowing if the IP address in your logs is the one doing the activity isn’t guaranteed. However… TCP traffic has a handshake, and in order for the replies to get somewhere, there has to be a valid “other end” of the connection. That IP address has to be a part of the connection for anything that needs replies (UDP traffic and DDoS? you’re on your own). The attacker may be using a bot net or another compromised machine, so just knowing the location of the IP address doesn’t give you the attacker (or file downloader….)

Used to be you could make a really good guess at the location of an IP address based on a traceroute and noticing the routers that the traceroute went through. You *might* get that information now – depends on if the backbone routers have ICMP turned off (most don’t) and how many hops you go through. If you’re going to an IP on the same backbone provider (or a very well connected provider like Google), you won’t get much information from traceroute. However, it’s a good first start.

WHOIS may also be another helpful tool. whois IPaddress will return different information than whois domainname. The returned information will show who owns that IP address according to the RIRs (ARIN/RIPE). Now, still not going to get you a jackpot every time, but it might. If the IP address belongs to a large organization who has its own IP address space assigned, you’ll have at least the company (and maybe the location, depending on how the company assigns IP addresses). You may also run into another wall if the whois search returns an ISP or hosting provider.

At this point, you’re slowly running out of free options. There are several companies who specialize in geolocation and are happy to sell you the information, which is how most web sites and services find that out (except mobile devices, which are a whole ‘nother ballgame). One service does provide a free database with less accuracy: http://ipinfodb.com/ It reliably figured out most of the IP addresses I tossed at it.

The big databases are put together in several ways: negotiating with ISPs and hosting providers to get the internal information (what dynamic IP space is assigned to the DC area vs the NY area), and just plain old brute work. Anyone remember several of the web sites that’d ask you where you were located??? Guess who ran those, and where that data is now.

In a recent study whole disk encryption (referred to as FDE in the study) has been shown to significantly hamper investigation. Basically, the encryption is too good. Even with techniques like cryogenic RAM freezing it’s often unlikely that the encryption can be bypassed.

But there’s a huge, gaping hole in such protection: you can’t USE encrypted data. For it to be accessible and usable, it has to be decrypted. (In other news, it is not possible to open properly locked doors, nor to pass through walls.)

And for the last few years, there has been a product out there which makes it possible to remove a computer without powering it down. This product is called HotPlug and it can be used, in conjunction with a portable power source, to remove a machine without disrupting its functioning. Be sure to watch the video.

Of course, lawful search and seizures aren’t the problem per se. But this does show that WDE isn’t a panacea. As with any security, it needs to be backed up by other defenses as well. Physical control trumps software security anyway. Which means, unremarkably, that even the newest technology doesn’t necessarily provide more security than a good padlock.

The lesson I learned then was that just because the hardware and software claim to be able to perform a function, it isn’t enough to assume that they actually work. Never assume – always test. Sometimes ports will be blocked; traffic won’t be passed, or there will be an absurd traffic shaping scheme that makes your particular application untenable. Sometimes these problems are resolvable, and sometimes they aren’t. This can be terribly vexing when trying to, for example, set up a VoIP connection.

But from a security standpoint, sometimes the reverse is even worse. What if the connection works, but the security doesn’t? This isn’t hypothetical. There have already been many cases of firewalls which implemented an IPv6 stack but didn’t apply the firewall rules to that stack – or expected a separate set of rules which had never been set up. And, of course, there’s always the risk of a lazy predecessor who, in the rush to Make Things Work set allow *.* in the rules – would you notice? After all, nothing would stop working. Well, until your systems got infected.

Fortunately, there’s a host of tools to save you from this problem. Your first is simple Defense In Depth – relying not just on one company-wide firewall but also on an IDS, software firewalls, and anti-malware software, so one foolish implementation doesn’t leave you wide open. Second, there are scanning and simulation tools – mostly port mapping, but a few others besides – which will tell you what ports are open and what services are actually available. And if that’s not enough, a proper 3rd-party penetration test will probably find anything. But your best line of defense is in your own head – knowing how your network setup should work, being able to read the configurations you have, and knowing if the actual results match up.

Now, while the bike ignition system incorporates both a physical key and a PIN, it’s clearly not two-factor authentication since you need only one of the two to start. Requiring only one OR the other obviously makes the system less secure for the sake of convenience.  Ducati could mitigate the possibility of randomly guessing the PIN by locking out PIN entry after five incorrect attempts, but it’s still inherently more vulnerable than just having a key and no PIN.  The same rules and guidelines apply here as in secure computing.

However, with just a slight change in the firmware, you could easily require both at startup, and voila, TFA.  It makes one wonder why bike manufacturers don’t implement this idea more often.  Or auto or boat manufacturers for that matter.  Yes, it’s normally straightforward for a skilled thief to hotwire the ignition and bypass a key altogether, but is it too difficult to implement an independent PIN input that is much harder to physically rip into?  Even if you could bypass it, surely TFA would deter a casual dishonest finder of lost keys.

We at Gemini are big fans of multi-factor authentication, and as more and more of everyday tools and applications utilize this feature, such as banks, Facebook, and Google, we can’t help but wonder why physical TFA is more often reserved for expensive high-tech facilities and safes than in the devices we use every day.   Certainly TFA is not indomitable, and it does not necessarily prevent phishing attacks, as one can tell from current news on ATM skimming, but it’s certainly a step in the right direction for anything worth securing.

I’ve been part of very few professional organizations throughout my career and college days. I even shied away from the women in engineering groups on campus, although I knew a lot of women in them. I tended towards the ad hoc, social groups instead. Blame it on the Cotillion club I was (forced to be) a part of when I was in high school, I just don’t like paying to be part of a “club”. I pay (ISC)2 only because I have to to keep my CISSP (and to other organizations for the same reason), I’m not a member because I believe in their mission or their goals. I think they’re overpriced and useless to me other than maintaining my credential (which is another can of worms…).

I’m more likely to be found at the local Linuxchix get together, or NoVAHackers because they are cool people who just happen to have the same interests I do. Yes, we’re “organized”, but I don’t have to pay to be part of the group (other than food and drinks, etc…). These folks I consider friends.

With the behemoth that is (ISC)2, I don’t even feel like part of the group. I’m assigned a number and then go on my merry way as long as I keep paying every year and submitting my CPEs. Which I’m perfectly happy to do.

I think the (ISC)2 has admirable goals, I’m just not motivated enough to care about them that much. I don’t participate in the elections (much), and I always pass up the proctor CPE opportunities and exam review opportunities. Could I help change the organization if I participated more – probably. And Wim Remes is trying to do just that by running for the board.

I don’t know what percentage of other CISSP holders feel like I do, but I’m sure I’m not the only one. And I’m not even sure that there’s anything (ISC)2 can do to change that – it’s not their “fault” we don’t care.

Any ideas or suggestions? Or arguments on why I should care more about the organization?

Jumio’s Netswipe is a new twist on entering payment card data online. Instead of swiping or typing, you essentially stream an encrypted video capture of yourself holding up your card. I’m assuming some OCR and heuristics on the other end translates those video frames into the actual card number. The resulting experience has the benefit of being keyless (immune to keystroke loggers), unsniffable (due to the encrypted stream), and easier than typing it out. The security benefits are complemented by the claim that the whole service is compliant with the PCI-DSS.

Yet, despite these kudos-worthy achievements, what new avenues are being slowly opened for exploitation by taking the tech in this direction? For example, when making purchases, I know what to look for to tell if I’m on a secure site (https and valid server certificate). But how do I quickly verify that my encrypted video stream isn’t being tampered with? If photo/video-enabled authentication becomes the standard, will phishing be just as lucrative on these new platforms? What about trojan’d hardware (webcams in this case)?

Innovation, especially in technology, can develop and mature despite a generally shady understanding of future implications. Sometimes, potential concerns are simply noted in passing, as if to say “we’ll cross that bridge when we get to it.” Other times, they are met with vehement resistance as issues of ethics and morality get debated. But I suspect the most interesting issues, the type that manifest themselves long after a technology has been adopted by society, are ones that were never even considered in the first place.

We ask about their security posture. Do they monitor entrances and exits? Do they police building parking? How is their alarm system monitored? How secure is their network? Are the cages secure? Who can get into the building?

We ask about their ability to handle disasters. What kind of fire extinguishers do they have? Do they use fire-resistant doors? Slab-to-slab construction? Can they handle flooding? Power outages?

But we need to start asking another set of questions: what is their legal posture?
A couple of months ago, an FBI raid at a data center in Reston took out “tens” of the data center’s customers, in spite of the FBI only targeting one client. The simple reality is that the average FBI agent isn’t a networking specialist, and may not be able to tell which hardware is relevant and which isn’t. And when they’re unsure, the FBI is likely to take everything and let the lab people work it out later. Sometimes quite a bit later.

So, we have to be asking how a data center will respond to such a circumstance.

First, it’s best if your equipment isn’t seized at all. As remarkable as it seems, many companies have a “complete cooperation with law enforcement” policy – if a police officer asks for something, they get it. Client data, equipment, facility access, anything. That’s not just fly-by-night places, either – I once worked for a hospital network with just such a policy. I’m sure the patients found that reassuring. Obviously, that’s not acceptable for a company with proprietary data. At minimum (and, in most jurisdictions, probably maximum too), the data center has to require that the police do their paperwork: only allow access to officers or agents who have a court order or warrant, and only allow the access specifically spelled out in the order or warrant, nothing more. In many cases, this will avoid the problems: if your iron is in cage 267, and the FBI wants to take the servers of your neighbor in cage 268, then the data center only allows them into 267 and you’re fine.

Second, if your equipment or data is seized – whether legitimately or by accident – then you had better find out from the data center BEFORE your customers let you know. This means that you and the data center need to keep a detailed inventory so you know exactly what was taken. And they must have a policy in place to call the affected clients immediately to inform them (i.e., you) when equipment is seized.

Third, you need fast recovery. This means offsite backups – so your backups can’t have been seized along with your servers – and a plan to replace the hardware. Because let’s be realistic: the police aren’t going to return server hardware soon enough. It’s almost certain that while going through channels and demanding that equipment is returned, you’ll lose more business than the cost of new hardware. This is especially true if your company actually is the focus of the investigation: it could be years before you get it back, if you ever do!

Lastly, you ought to make sure that your information is protected. Whether your servers were taken by the FBI, local law enforcement, or thieves, you don’t want anyone reading it without your permission. That means encrypting your at-rest storage AND your backups. Granted, this doesn’t necessarily keep your data secure – they can always get a court order for you to encrypt your files – but it keeps you from being in the same boat as Instapaper and it’s just good practice.

Odds are you’re not going to be raided by the FBI. But you really ought to have a data center with good site security, an up-to-date inventory, and a prompt notice policy anyway. And you should have your data encrypted and keep a Continuity of Operation Plan in place. These are measures you should have been doing already; they just happen to apply perfectly to this scenario, too.

These observations underline much of the recent grumbling about the use-your-real-name policies of some web sites. Facebook and Google+ (and there are many others) may have a perfectly legitimate reason for requiring true names to use their service– and even if they don’t, hey it IS their service and users have to play by their rules. But if this becomes a more common practice overall (websites are frequent bandwagoneers), the grumbling may turn into fists and pitchforks. The whole situation is made even more complex by politics. Are we seeing a paradigm shift in how we associate with each other? More importantly, have we already arrived at the dystopian future of name paranoia and government ascendancy like that found in Vernor Vinge’s True Names?

With more and more devices being “always connected”, I suspect we’ll see more problems. And these are the kinds of problems that may literally be life and death – turn someone’s heat off on a cold day, start a car in a closed garage, etc. Today, we assume that all Internet sites have a modicum of security knowledge, or someone has at least thought about security. Is the same true for these new technologies? In general, the Internet doesn’t control life and death – yes, it’s annoying when someone steals your credit card number, but you’re not (likely) going to die from it. These new systems are – and I suspect that security hasn’t been at the top of the designers’ minds.

That probably sounds like an awful lot, but in truth it isn’t. It’s awfully difficult to find exact figures on regulatory fines – companies tend to be rather tight-lipped on the subject, after all. But on the scale of companies and business fines, and knowing that companies in general, and hospitals in particular, are generally good at cushioning themselves against such damage, it’s just not that much.

Also, HIPAA is considered something of a paper tiger. Although HIPAA was passed in 1996, there weren’t any fines issued until 2006. While there have been quite a few fines and even criminal prosecutions since then, and the UCLA fine is the third “large” fine in 2011 – the largest being $4.3 million – that’s still not all that much on a business scale.

However, HIPAA compliance is a major concern for healthcare providers; a concern which is far out of proportion to the expected costs of non-compliance?
Why? Are all hospitals, insurance providers, and private practices that concerned with patient privacy?

I’d like to say yes. But, cynically, my time working at a hospital tells me the real reason: they don’t want to undergo an inspection.

HIPAA originally set the maximum fine for each individual violation at a mere $100, with the maximum possible fines being $25,000. Those limits were raised in 2008, and there is a risk of criminal penalties to boot, but that’s not the biggest risk, nor the biggest potential cost.

Each reported violation can trigger a HIPAA inspection. Inspectors can look over the entire facility, from top to bottom, looking for each and every violation. The costs involved in such an inspection, in terms of disruption to the facility, far exceed the possible fine involved.

The numbers don’t tell the whole story with HIPAA. The fear of an inspection has motivated hospitals throughout the nation to adopt far more secure practices with respect to medical records. While there can, and will be, data leaks, HIPAA is more effective than it seems.