A few years back, I was working as a tech writer for a company which made medical software. We were trying to get an important certification that we’d need to sell our product. And a crucial part of that was good documentation: we had to show how it worked, what it did, how it tracked everything, how it was secure, etc. Well, that’s what you have a tech writer for, so all is good.

It’s important to know, I didn’t have any existing documentation to work with. There was a wiki which had the developers’ notes in it, but that’s it. Nothing by way of formal hand-it-to-an-outside-entity documentation.

Okay, that’s not too abnormal; tech writing is expensive, and many companies don’t bother with it until an auditor is breathing down their neck. Hardly ideal, but to be expected, and I did have time. So, I set to it.

Since there wasn’t any existing documentation to re-do, I based my organization around the expectations set by the certification. And, a good week before the deadline, I turned in the completed documentation, all 100-something pages of it.

And that’s when disaster struck. The auditors decided they wanted the documentation in a completely different format – they weren’t going to read our documentation, no. They wanted us to fill out a questionnaire. The questionnaire was very comprehensive, encompassing exactly as much material as my documentation covered. And I had less than a week to complete it. I told my boss “No problem.” And I gave him the completed questionnaire in 3 days.

(more…)

I recently had the pleasure of performing one of the best security assessments I’ve ever done. It was great: I didn’t find any gaps. Not a one.

To some people, it might come as a surprise that I’d consider that a good assessment. And I’ll admit, it made me a bit suspicious. Nothing? Seriously? Well, I had to look into why, and I’ll get to that in a moment. But let’s cover something else first.

I’ve been on both sides of the table for security audits. Being audited is Not Fun. You have someone coming in, looking over all your processes, and it’s up to you to prove that you’re doing what you’re actually doing, often for reasons that seem terribly arcane or pointless. And the management directive is almost always “make sure we pass this” which is assuredly not the same thing as “make sure we are actually secure.” It’s a very adversarial relationship.

As the auditor, you’re always looking for the places where they’re trying to hoodwink you, trying to gloss over something, or just outright lying. You’re always suspicious. If you’re not when you start, you will be. Because the people you’re auditing don’t want to be secure – they want to pass the audit. Which is understandable – failure can mean losing their license to operate, losing a major contract (clearly, one that’s big enough to bring in an auditor!) and in extreme cases bringing down the company.

It doesn’t have to be that way. As a security analyst, my goal isn’t to find problems. It’s to locate any security gaps that may exist, and where appropriate offer remediation steps.

Aren’t those the same thing, though?

Well, no. As the old saying goes, “seek and ye shall find.” I’ve met many auditors who took delight in writing overwhelmingly negative, scathing reports. They’d pounce on any excuse to fail a control. Which sounds like they’d at least be informative, but realistically the resultant reports aren’t all that useful – they don’t give much true concept of the security posture of an organization, because they’re invariably negative.

The problem is that nobody is really looking at the true purpose of security audits and assessments. Organizations being audited just want to get through the audit. The auditors are trying to “catch” the organization. But security audits aren’t high school tests or witch hunts. The end goal isn’t the report. The end goal is an organization, system, or project with a good security posture and no known gaps.

That’s what made the assessment I did last week so unusual. You see, they were given the standards in advance. They knew exactly what I was looking for – and so they went out of their way to make sure I’d find it. They had purpose-built the space specifically to meet the standards. There was no gotcha, no hidden agenda, no posturing or hiding. I knew they’d set things up to make sure my assessment would be good – and that’s great. It’s the way it should be, and the result was a completely clean assessment.

Of course, there is a risk. Organizations may know what the standards are and then try to pretend to follow the standard, or look for loopholes. That’s where the auditor really comes into play – to recognize when an organization is trying to follow the letter but not the spirit of the standard. But the most important thing to remember, for both the auditor and the auditee, is that the goal ultimately, is security – it’s not to play gotcha, it’s not to hide gaps. It’s to find and close the gaps that exist.

While I did my thesis on this topic back in 2001, I haven’t used the knowledge or skills I gained from it much – or really at all. But I think it’s an interesting topic, and one that security folks and system administrators should at least be passingly familiar with. The technology has certainly changed since I did my thesis.

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.

I’ve mentioned Whole Disk Encryption in the past. There are a number of products, both free and paid, which will allow you to encrypt your entire hard disk, or the hard disks on your servers.

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.

I am currently experimenting with my smartphone, to see if its Mobile Access Point Functionality allows it to function as a wireless router independent of Internet connection. In theory, it should – it is capable of providing internet access to four attached devices, and that suggests that it should have router functionality, meaning that the attached devices should be able to talk with each other, rather than simply to the Internet. In practice, I know that sometimes seemingly important parts of networking implementations are, well, not implemented. The most egregious example, in my experience, was a commercial-grade firewall which was unable to pass UDP traffic under certain circumstances.

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.

We’ve discussed the importance of properly implemented two-factor authentication before, but TFA is usually associated with computing fields or high-security facilities.  Earlier this year an InfoSec blogger wrote about his experience driving a new Ducati Diavel, in which he dealt with a dealer who did not provide a key for the bike he was test driving.  While the bike appeared to have been started before he left the dealership, apparently the dealer started it without a key, since new Ducatis can be started with an optional backup PIN in case you lose or forget your key fob.  To his surprise, the bike’s PIN was the last four digits of the bike’s VIN, although that was most likely an oversight from the dealer, not the factory setting, which is to have the feature disabled (Hint: You should never make your passcode for any authentication a number or phrase that is publicly available or related, like the VIN).

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.

Let me first start off with the disclaimer that I am a CISSP and (nominally) a member of (ISC)2.

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?

In the past few years, we’ve seen point-of-service payment card hardware and software capabilities extend from an enterprise level (proprietary systems) to a small business level (financial instutution-backed merchant accounts) and finally to an individual level (web and mobile payments). And it makes sense; despite the growing popularity of e-currency, most people with a bank account have access to a credit/debit card and aren’t afraid to use it. And with each step of maturity, the technology surrounding payment cards gets more and more diverse and open to innovation.

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.

When contracting with a data center, we ask plenty of questions.

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.

What’s in a name if it’s transparent? The concept of a “name” has always been an important part of interactivity due to the convenience of association. We use names to keep people and things distinct when we reference them. Beyond that, their significance can be magnified by the value we place on them (e.g. exorcisms, Rumpelstiltskin). It stands to reason that one’s true name, being something of value, would be protected to some extent. We typically accomplish this simply by sharing it selectively, or by using a partial name or a nickname. Our experiences online aren’t much different; pseudonyms have long been part of the fabric of the Internet and are basically e-nicknames. Handles, monikers, and ICQ numbers have all provided the ability to identify an individual without divulging their actual name. Moreover, since a pseudonym has the characteristics of a name, it can be uniquely valued as well– it’s not uncommon to build a significant social identity around one.

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?