Securitrons and the Thunk Test

Best Practices, Management, Security Policy, Standards 1 Response »
Jan 212010

An increasing amount of security work these days is very academic and theoretical, rather than hands-on.  The development of risk management (a.k.a. “covering your ass”) as a serious factor driving security awareness over the past ten years has led to a massive amount of paper-generation and abstraction, going hand-in-hand with ever-more-complex attempts to needlessly quantify security realities.

Partially this stems from the desire to apply financial metrics to risk and security, partially from the need of managers lacking a strong technical background or the ability to acquire this to have easy-to-understand, purely numerical descriptions and graphs of where their money is going.

One of my colleagues recently came up with the concept of an abstract measure of security investment (time, effort, grief, etc.) — the securitron.  As in (hold hands zombie-like out front and repeat in a robot manager voice), “we’re going to need more securitrons!  Throw two hundred additional securitrons at this project!”

For some reason, this came up again during a meeting to discuss increased efficiency of risk management paperwork.  The upshot of this meeting, as with pretty much any business meeting consisting of over three people (and not taking place by the coffee machines, where most productive work gets done), was (a) use your own damn judgment, that’ s what you’re paid for, these are only suggestions, (b) if you still have questions, ask your colleagues, that’s why we sit together, and (c) when will this damn meeting end?

However, an interesting point did arise — the idea that security, risk management, and compliance work tends to end up with reams of paper that may or may not ever be read.  This was the case with all medical regulatory and compliance work I’ve ever done, as well as with pretty much every experience I’ve had in financial services since 2000.

The conclusion?  My personal view is that documentation and paperwork does not make much sense unless it’s in an easily accessible format (e.g. a well-organized database schema accessible by very flexible views to whomever wants to use and evaluate the data.)

Another very important point that my colleague raised, though, was the concept of the “thunk test” — i.e. if a security policy is dropped on a desk and makes a “thunk”, it’s too big to be of any use.  Nothing that heavy can possibly have the elegance and simplicity to be easily enough understood for practical everyday application.  At the risk of advocating the development of tired business doublespeak, I could see a use for a plainly worded non-mealy-mouthed type of goals and rules statement (“don’t leave passwords lying around.  Never talk to strangers.  Don’t pet strange dogs”) for security organizations that actually fits on a single piece of A4 paper (or at least in a document that makes no more than a soft whisper as it’s dropped.)

Now, we are working on finding a good name for a measure of the quantitative relationship between securitrons and reams of paper.

Posted by john at 10:54 am

Autistic Security Event Monitoring

Best Practices, Management 1 Response »
Sep 232009

Wired Magazine recently published a set of articles titled 12 Shocking Ideas That Could Change the World. Among them was a suggestion by a Danish gentleman named Thorkil Sonne, of Specialisterne, to hire autists.  His reasoning is that people with autism or asperger’s are good at routine tasks;

“As a general view, they have excellent memory and strong attention to detail. They are persistent and good at following structures and routines”

So, I got to thinking; one of the discussions I had with colleagues following a recent meeting with a provider of managed security services (see previous post) dealt with the idea that building and maintaining a decent SOC and log/event management procedure is a near-impossible task, due to the difficulty of creating a sustainable operations process; one of my co-workers made the point that most people would tend to get bored with the repetitive nature of looking through logfiles, or even dealing with things like security advisories and updates.

I countered with the assertion that your basic event management and intelligence correlation should, to a large degree, be automated anyway (whether non-dedicated companies can do this as well as, or better than, dedicated outsourcers is a separate discussion that’s probably best investigated on a case-by-case basis.)  However, the routine nature of any IT operations-type job aside, he did have a point that (a) even when you do automate everything, you’ll still want a degree of human second-guessing, and (b) that gets mighty dull.

It seems like a logical conclusion that if Thorkil Sonne is right, and autists (is that a word?) can really be excellent at work that requires focus, consistent attention to detail despite the drudgery involved, and clear rules, why not use these guys for exactly the tasks described above?  Someone who is excellent at pattern detection, and is willing to follow the same process day after day after day would seem to be ideal for an SOC monitoring / log & event analysis position.

I don’t want to come across as somehow insensitive, since I know next to nothing about autism, but purely going by the value proposition put forward by Specialisterne, it seems like a rational conclusion to hire the best people for any given job — whether or not the fact that they are qualified at what they do stems from extraordinary dedication, experience, or a mental condition should be completely irrelevant.  And in the process, maybe do some good for someone who might be difficult to employ otherwise.

Posted by john at 6:26 pm

Modularizing Security Functionalities

Architecture & Design, Best Practices, Development, Standards No Responses »
Mar 272009

Okay, I made up “modularizing”, but I think it nicely fits the idea of this article.

I am a huge fan of the concept of abstracting functions — i.e. clearly defining what it is you are trying to accomplish with your various bits of software & hardware, defining clear categories for their functionalities, separating them, either physically or logically, and ensuring that everything communicates via clearly defined, standards-compliant interfaces and APIs.

During several early projects of mine, I noticed that the temptation was strong for managers to create all-in-one tools in order to sell the widest package of application functionality conceivable.  This is bad design, if only because different uses and scenarios can have different requirements; addressing these may have unintended network effects on other components of a product, thereby slowing down the whole analysis, development and QA process.

One of my clients has taken the path of a pluggable, modular configuration tool for some of their systems; this is a good model insofar as it allows clear access to different components from a single interface, but the components themselves are not interdependent.

For the purposes of this article, I’d consider using very basic distinguishing criteria like “network / communications device”, “end-user application”, “remote support tool”, whatnot — and in the scope of this article, “security device” and “other.”  I realize that these are fairly theoretical, academic distinctions, but it’s my firm belief that the idea applies in real life. Such a matrix can be multidimensional — criteria could include, on the one hand, what the application is used for, and on the other, how it is deployed or managed, OS type, manufacturer, etc.

For example, one of my projects involved the development of a small network security appliance for a specialized scenario (protecting proprietary devices subject to strong regulatory requirements.)  There was constant pressure from sales & marketing to avoid having multiple physical boxes; the field service types also wanted to prevent having to maintain additional distinct hardware.  This was a good example of when it was right to not listen to our customer and push them to accept the idea of having another little small piece of hardware; integrating the security into pre-existing products would have required a huge amount of adaptation, porting, maintenance, testing and other effort, over multiple architectures, teams, countries, whatnot.

“Security” is a compelling argument for the separation of protective functions from what’s being guarded; there may not be a clear, identifiable exploit that you are addressing, but, using the example of network defense, knowing that your authentication, detection, encryption and filtering tools are autonomous from each other reduces the possibility of single points of failure.  I’m not arguing for an eggshell model of security (crunchy on the outside, squishy on the inside), but it makes things much easier to be able to address an application server’s security requirements without the need to assume that whatever security you implement on an application level is all you will have.

An even more significant reason to keep things separate (physically, via dedicated, standards-compliant hardware, or virtually, via VMs) is cost reduction — support and development are simplified.  Despite the appearance of increased complexity from more components, if you are able to quickly and easily swap out a defective element, or create added functionality whose impact on an unrelated system is controlled through a standardized network interface or code API, you no longer have to worry about breaking things that should be out of scope for whatever it is you’re doing at the moment.

Posted by john at 1:27 pm

Firefox 3's Horrible Unsigned Certificate Handling

Authentication, Best Practices, Crypto, Social Engineering 3 Responses »
Mar 242009

Following an interesting discussion on the ZOG security mailing list (which is so elite and secret that, should you be interested in joining a bunch of security guys bashing on Windows and planning beer & pizza excursions, well, enjoy – NO HEADHUNTERS) I thought I’d share my blather on why, frankly, Firefox 3′s self-signed certificate handling sucks.

Don’t get me wrong, aside from the bloat I love FF.  It’s like Apache — it’s a resource hog, but it does what you want nicely, and it’s kind of like a pair of old underpants that you can’t quite bear to throw away.  But this one particular bit of chicanery just stinks.

In case you forgot, when faced with a certificate signed by a CA whose root certificate is not in FF’s certificate store, you receive an obnoxious set of messages (here on a Mac:)

ssl

Oh noes, a cop.  It must be bad!

ssl-1

“Legitimate…other public sites will not ask you to do this.”  Screw you.

ssl-2

“This site attempts to identify itself with invalid information.”

I am doing no such thing.  Rather, I am attempting to encrypt your data transmission.  My site has no reason to identify itself to a client.  Yes, this goes away after the first time, but boy, what a way to scare off potential visitors?

Like Opera, and in contrast to Google Chrome, Firefox does not use any OS built-in certificate stores, such as Windows’ MSCAPI.DLL or MacOS X’s keychain access.  I assume this is for ease of cross-platform maintenance) but it does make it less likely that anyone will use certificates installed universally as part of a Mac package or Windows MSI installer or equivalent.

Thankfully, StartCom Certification Authority is now included by default; CACert, in addition to providing fairly short-lived certs (full disclosure:  I am a CACert assurer of some sort, or at least I was before I completely forgot about it) appears to have failed an audit at one point; Axel Eble points out that Ian Grigg, of Financial Cryptography, is currently conducting an open audit of CACert.

As far as free certificate issuers’ root certificate inclusion in Microsoft products goes, the company’s CA certification policy is pretty hairy — looking at the technical and audit requirements, an open candidate for inclusion in the Windows / Internet Explorer certificate store will have to muster significant financial resources.  Even if this were the case, there’s the interesting catch-all near the end of the requirements, disqualifying

“CAs who fail to meet the burden of proof for the broad business value of their offering to Microsoft customers.”

Without any criteria on what this constitutes.  At least IE’s self-signed certificate warning is a bit less cumbersome.

Commercial certificates cost a fair amount of money, starting at USD $150 for a 1-year basic SSL cert from Thawte, essentially for no incremental cost once they’ve passed their audits.  It’s a money machine, although I can’t fault them for it; I’d try to make money off a broken model too, if I could.

Why is this an issue?  Because the more the use of encryption permeates the Internet, the better.  Call it a distrust of authority, a desire to see increasing amounts of personal data secured out of general principle, a fundamental interest in an overall increase in entropy (let’s not get into the reasons why hiding, obfuscating and protecting your data is necessary — I will simply revert to the old and invincible argument about “you close your door when you use the toilet, don’t you?  What do you have to hide?”)  I want to see everyone and their dog use cryptography, if only for the purpose of letting Joe Schmoe acclimatize himself to the fact that it is not only possible and perfectly legitimate, but actually a very good idea, to encrypt things.

A big scary looking warning creates fear and distrust in the minds of nontechnical users when they visit a site with a self-signed certificate whose purpose is really only to keep the transmission of data-that’s-nobody-else’s-business secure (in addition to being a very small pain in the ass to those of us who have to click through the annoyance every time we want to log into our private web services from a different browser.)  Is that the point?  What about this?

pgp

Nice one, PGP.  Might want to talk to your customer services provider (that is, or at least was at time of writing, their actual site.)

Ian Grigg makes a good point — “I despise and loathe the idea that to use crypto you have to know me.”  As such, I agree with the idea that it’s pretty dumb to combine the handling of credentials used for encryption and identification of sites.  From what I can tell, the latter is Mozilla’s main concern with the hoops a nontechnical user has to go through to make sure a site is “legit.”

I understand the idea of wanting to make it clear that a certificate not signed by a “reputable” CA may be masking a phishing or otherwise fraudulent site.  However, one way around this would be to have two classes of warnings — one a simple check whether the FQDN of the website is identical to that of the host the certificate is created for, with a big friendly easy-to-understand information message stating something along the lines of “this certificate is for host xyz.com, please make sure the address in your browser bar is the same” with a simple list of cautions below it.

Bonus points for separating the authentication and encryption portions of an SSL connection — tell the user “the site claims to be xyz.com but may not be, but your transmission is encrypted, do not enter sensitive data, such as credit card or personal information, unless you’re sure whom you’re talking to” and basta.

The second use case, for certificates authenticating a site and encrypting a connection, should check far more strictly that the issuer is legitimate.  In this case, the end-user has a genuine need to know that the certificate issuance process is tightly controlled via a trusted party — the CA root cert included in the browser store.  Fair enough.

Yes, the average “user” may not have much clue, but excessive mollycoddling at the expense of usability is bound to be counterproductive — it scares people away from increased use of crypto, and annoys the rest of us with way more obstacles than are necessary.

Posted by john at 1:35 am

Why Biometric Authentication is (Frequently) a Bad Idea

Architecture & Design, Authentication, Best Practices, Identity Theft, PKI, Privacy, Social Engineering No Responses »
Feb 272009

Authentication Basics 101

First, some three-point lists to re-hash the elements of authentication, mainly for my own memory-jogging purposes.

An individual who wants to gain access to data or facilities goes through a three-stage process:

  • Identification (”Hi I’m Bob!  Let me in!”)
  • Authentication (”OK, I verify that you are indeed Bob.”)
  • Authorization (”Bob, I verify that you are among those permitted to enter.”)

Authentication can be done using any combination of the following three ingredients:

  • something you know (e.g. password, PIN code)
  • something you have (e.g. key, smart card)
  • something you are (e.g. fingerprint)

It’s been a given for a while that two-factor authentication is a good way of massively raising security of information or premises at a comparatively low cost, by reducing the impact from losing or disclosing any part of the authentication process.  If I drop my access badge on the train, big deal, because I also need a secret passcode to enter the office.

Some Problems (PKI / Certificate Example)

As a quick side-track, during every single PKI-related project involving token-based authentication (usually smart cards) that I’ve ever worked on, two major issues inevitably arose:

First, how do we adapt peoples’ credentials to changing circumstances.  For example, the subject marries and changes their name.  Signing keys used in authentication certificates can be expired or revoked, even though this requires maintenance of a functioning certificate revocation list, something a lot of enterprises don’t seem to be capable of, and which can be technically daunting in any case once you start dealing with multiple thousands of revoked certificates.  However, data signed and encrypted before the expiration or revocation date must be accessible or verifiable in perpetuity, no matter if Jane Smith is now called Jane Smith-Jones.

Continuing the certificate example, this is solved by using something like friendly names on certificates (where the user’s name is not part of the certificate’s LDAP distinguished name (DN), or unique numerical identifiers that are mapped to an actual name in a database accessible by other applications that use the certificate.  There are many ways to skin a cat, or a user who changes their name.  However, this falls squarely into the “bad planning” department that seems to be an attribute of many PKI deployments; architects often don’t make allowance for future requirements, such as extended key attributes (thanks for the tip, Arjo), thus raising the need for additional certificate rollouts and system redesigns.

Second, what happens when the user loses his chip card?  No problem, get him a new one.  Even better, prevent him from losing it in the first place, by combining his authentication token with something he is definitely not going to forget, like the bathroom access pass or his lunch card (but whatever you do, please PLEASE don’t put the company logo or address on his access badge.)

What to do, though, when he’s on a service visit to a missile silo at the North Pole, or with a client in Colombia, and can’t access his laptop?  What about one-man branch offices in Timbuktu?  This is where we start facing increasingly complicated problems with issuing emergency credentials via cell phones (a great medium for secondary authentication — they’re tied to a person, they’re at least somewhat secure against casual attackers via GSM encryption and PIN code access, and they’re one of the least likely items to be forgotten at home.)

Moving beyond the scope of digital certificates, biometric authentication offers a tempting solution for both of the above problems..  Passports can be forgotten, passwords extorted, and unless you’re using a system that doesn’t check for heat or blood flow (useful in the case of the Malaysian Mercedes owner several years ago whose fingers were severed by robbers to gain access to his fingerprint-protected car) or which can be fooled by fake biometric credentials, biometric authentication immediately and reasonably reliably identifies and authenticates a user in one go.  Unless he loses his hands or voice or has his eyes gouged out, but that eventuality doesn’t look so nice in the authentication product marketing brochure, so we’ll conveniently ignore it.

Passwords are Annoying

Passwords have their own problems; I agree that people should use pass phrases instead of passwords whenever possible [1],[2].  Furthermore, I believe that excessively strict password complexity and rotation rules lead people to do stupid things like (with all due respect to Bruce Schneier) writing down passwords in obvious places.  Very few individuals have the time, knowledge or intelligence to write down passwords in a way that keeps them safe (plus, the “YOUR PASSWORD WILL EXPIRE IN 5 DAYS” warnings on Windows workstations tend to catch people when they’re most stressed and hurried to log in and get to their meeting.  Furthermore, password vaults tend to be impractical if, like me, you access similar resources from different workstations, laptops, interfaces, etc.

Biometric authentication gets around all this; in the case of a lot of low-end applications, such as unlocking laptops, it is a thoroughly convenient mechanism that allows administrators to get around the expense and complexity of dealing with things like BIOS/startup authentication, or the aforementioned user failings in dealing with password security rules.

So Where’s the Problem?

There are a number of classic arguments against biometric technology — principal among them being that, in case of identity theft, it is not possible for a user to change his credentials, ever.  My major objection to most uses of biometric authentication, however, is the excessive trust placed in it, combined with the absence of non-repudiation.  While most technologies involved are technologically sound and deployed in a well-meaning manner, these related failings bear the probability of inevitable negative, unintended side effects.

By virtue of its perception as an advanced, “futuristic” technology, there is a tendency to ascribe some degree of infallibility to biometric authentication.  Errors are viewed as improbable; since there are no longer external factors (knowledge or objects) involved in authentication transactions, the person logging in with a thumbprint must perforce be the owner of the thumb who was registered as such.

As an analogy, DNA matching by police suffers from a similar weakness; first, we cannot discount concerns about false positives.  Even if there is a one-in-a-billion chance that a DNA sample from a crime scene matches an innocent person as well as the perpetrator, statistically this may be acceptable, but wouldn’t it suck if you were that innocent person?  Is this tolerable?  Furthermore, as the John Schneeberger case demonstrates, even if the technology were flawless, completely circumventing the context within which DNA matching functions, by means of such shenanigans as introducing fake DNA, the entire usefulness of an otherwise good system is thrown out the window.  This is similar to the famous analog hole argument about why media digital rights management is a fundamentally broken concept; even if the hardware and software works just fine, a method completely out of its scope will render its deployment irrelevant.

In the case of biometric authentication, there are a number of conceivable (and, in my case, for lack of greater expertise, purely theoretical) situations where its employment breaks down; this xkcd cartoon demonstrates one such eventuality in a fairly insightful manner.  Given that many people will be subconsciously awed and intimidated by the cool sci-fi retinal scanners at airports, or palm readers in front of offices, this translates into a disregard for the possibility that something will go wrong with the system — dangerous because, even if the security of the system itself were flawless (which no system is) it can probably be circumvented, somehow.  This brings us to the second, and greater danger, that of the lack of non-repudiation in biometric authentication.

By means of overview, digital identifiers are used in two related but different ways to determine the authenticity of data — signing tells the recipient of data, “the information you received is the same that was sent, and it is I who sent it.”  This comes in the form of MD5 checksums, PGP signatures, etc., or in archaic terms, the royal seal on an envelope — in x.509 terminology, signing keys with an authentication bit set in their certificate containers are normally used for certificate authentication (as the key is used to sign a set of credentials transmitted to an application and to guarantee their inviolability.)

Non-repudiation means that a recipient of information can be assured that the originator cannot deny that he provided certain information; the recipient can prove that something not only originated with a given person, but that person is not able to reneg on the information.  Signatures on credit card slips or notarized contracts are the most common real-world examples of this.  There is a subtle difference between the two — signing assures the recipient that information and sender data are correct, non-repudiation guarantees the recipient that the sender will abide by the terms of the information received.

Authentication by biometrics introduces the idea of non-repudiation into a transaction where it usually has no business.  A user is first identified, then authenticated.  Both of these components of the authentication transaction three-step process take place using the same single medium — part of the user’s body.  This is bad.  As the user is identified as who he is, the authentication process suddenly and automatically includes an audit trail — which cannot, by definition, be contested.

When John Smith, average employee, sits down to log into his company workstation, he enters his username and password.  Even though his username may be “smithj”, which is tied his employer’s Active Directory to his username and photo, the disconnect between the person and the authentication framework means that he is not treated as an individual, but rather as an anonymous construct that possesses, hopefully legitimately, John Smith’s authentication credentials.  Can I prove that someone did not steal John Smith’s username and password?  Not really.  Maybe he wrote it down — perhaps that’s a firing offense in itself, but there is at least the reasonable doubt that it was he who logged in.

Not so with biometric ID.  The moment he swipes his palm across the door entry plate, or looks into the airport retina scanner, even if there is some doubt that it is, indeed, John Smith requesting authorization, that doubt enters the realm of the statistically irrelevant.  Fine for criminal prosecution, but decidedly suboptimal if you are John Smith who spent his Sunday in bed with a book rather than breaking into his workplace with a fiendishly clever copy of his thumbprint, or by jury-rigging the actual scanner with a battery and a bunch of wires.  The fact that it was a physical part of John Smith that was used (in the mind of the authentication system) to open the door or unlock the workstation means that the audit trail automatically associates him with his action.

This extends to a person’s movements between countries, his use of a cell phone, his travel in a car, his purchasing habits — all of which can be plausibly denied and repudiated if physical or virtual items, such as passports and PIN codes, are used to authenticate the user.  Identity theft at this point may be unlikely, but fatal for the victim.

How to Fix This

Biometric authentication is not fundamentally bad.  It has its place, if properly planned and implemented, and if the consequences of its use are known.

For example, authentication can be insular and local.  That is, the process does not register a user’s physical characteristics anywhere centrally, but rather uses a locally cached checksum of, say, a thumbprint to unlock a laptop or smart card — similar to what many Windows-based thumbprint login mechanisms already use.  A kerberos exchange is made with a domain controller, as with a username/password or smart card login, but the actual physical characteristic is not associated in its “raw” form with any central user profile.

Second, biometric authentication must absolutely under no circumstances be tied to audit trails; the tracking of a user’s actions and movements is information desired by law enforcement, human resources, marketing wonks, scammers and any other number of other parties, but there is no reason to tie a user himself, through his physical qualities, to his actions.  I want to be able to deny that I used my credit card in Indonesia last Tuesday; the moment this ability falls due to the authority of a retinal verification for a card transaction that was somehow falsified, I have a huge problem.

Next, such authentication must not cause anyone to come to harm.  As with the Mercedes example above — people are (usually) more important than objects or data.  If you evaluate your security needs and believe it’s a good idea to force someone to go through a burly Secret Service guy to get to the nuclear launch codes, that makes sense.  However, endangering someone’s safety for a car or laptop when it’d get stolen anyway, no matter what they do, would be callous and pointless.

Lastly, authentication credentials must not be tied to any other stored instance of a person’s biometric information.  This sounds paranoid, but physical characteristics, since as we see above these are refutable only with difficulty, and credentials can’t be changed.  The instant someone is able to abuse biometric credentials, a user’s entire financial credibility, his workplace history, and any number of other valuable combinations of reputation and resources may suffer.

Posted by john at 7:50 am

De-Perimeterization Done Right, Part II

Architecture & Design, Authentication, Best Practices, Development, Network Security, Privacy No Responses »
Dec 142006

The core of any mobile working solution will always be a laptop, most likely running Windows XP (as of present I am not aware of any companies with concrete plans for large-scale Vista deployments.) The first step is to define some overall requirements for our solution:

1) Transparency and usability of security mechanisms whenever possible
2) Prevention of unauthorized access
3) Anonymity
4) Easy replacement of lost or compromised assets or data
5) Plausible deniability by users of data on their systems
6) Traceability
7) Ease of management and support of users and assets
8) Expandability and portability of the solution

Any mobile environment should be usable by all users, regardless of their security profile, so we will be relying on as much automation and build standardization as possible.

We start by breaking down the productivity requirements into two classes: sensitive (having to do with company-internal infomation) and general (contact to others via Internet.)

The basic functions that we want are thus:

  • Basic office productivity tools (documents, spreadsheets, presentations, similar tools)
  • Mail (secure when needed)
  • Other communiation and collaboration with internal users and external persons (such as chat and VoIP — secure when needed)
  • Browsing (secure Intranet sites)
  • Browsing (other)
  • Secure document & data storage (local and remote)

So essentially, we can group all these requirements into two rough clusters:  “stuff that needs to be very secure” and “stuff that doesn’t need to be that secure” (beyond the usual protection from everyday badness.)

The solution we came up with for all these requirements was a multi-tiered model, using a couple of commonly available tools.  Yet another short ingredients list:

  • Layered access control (boot sector protection, full disk crypto, a strong authentication model) for the laptop itself
  • An “inviolate” stronghold (such as VMWare ACE) running on the laptop — this is the only environment from which the more secure internal functions, such as corporate groupware and file sharing can be run
  • Integrity policy (mixture of Microsoft AD GPOs and Check Point integrity client)
  • A relayed VPN connection — via an offshore VPN gateway — so casual sniffers have trouble tracking the destination of your VPN link
  • Live remote AD logon — Check Point, and possibly other vendors do a really nice thing called “SDL”, or Secure Domain Logon, where your Windows AD credentials are taken from the MSGINA into a “holding pattern” until a VPN connection is established (via a “shim GINA” that comes right after the MSGINA), at which point you are given a full live AD logon, as opposed to authenticating to the locally cached auth credentials
  • PGP-based optional mail and file crypto, allowing for greater flexibility with removable devices (corporate ADKs, or additional decryption keys, deal with all those pesky recovery issues)
  • Terminal-server based applications and filestorage for sensitive material; Citrix or Microsoft Terminal Server both do the trick here.  The point is to add another layer of security between the laptop and the crown jewels, and to remove the need for remote workers to store unnecessary but sensitive materials locally.

That’s it for today, class.  At some point I’ll go into what to do about remove laptop recovery, allowing users to have data auto-destruct without incriminating them or garnering accusations of impeding investigations, and other cool topics.

Posted by john at 11:38 pm

De-Perimeterization, Done Right (Part I)

Architecture & Design, Authentication, Best Practices, Development, Network Security, Privacy No Responses »
Nov 272006

In March 2005, Brazilian federal police raided the offices of a Credit Suisse subsidiary in Sao Paolo. In addition to arresting the local management (and from what I understand, keeping them incommunicado for something like 48 hours), the Brazilians probably also had unfettered access to at least parts of CS’ worldwide corporate network. Similar harassment of international companies, both legitimate and arbitrary, has occurred in Russia and other countries.

Not all governments welcome the presence of high net worth private banking client advisors, or representatives of competitors to national champions in their jurisdiction, and such individuals should worry about industrial espionage. Furthermore, countries such as the United States have enacted restrictive immigration policies during the past few years, which allow pretty much unfettered access to laptops of business travellers. Several colleagues of mine entering the US for security conferences have been harassed upon identifying themselves as security consultants or experts.

Additionally, the maintenance of a fixed office may simply not be economical in certain regions, especially when individual sales reps, consultants or other professionals cover large geographical areas. The laptop should thus function as a completely secure, untraceable, self-contained office environment, giving the user access to all functionality he would have at a fixed, secure office but without endangering company data, user safety or corporate infrastructure.

One of my on-again off-again projects is the design of a secure mobile platform. Beyond the usual full-disk crypto + VPN solutions used by most companies with executives on the road, I believe that a true mobile architecture involves several more parts that are often ignored.

The Jericho Forum proposes ‘de-perimeterization’ as the removal of fixed barriers to the core network; they do not, however, offer a great deal of substance or concrete suggestions. To this end they are occasionally criticized, although in this particular case I can’t agree with the author. IPSEC may have its weaknesses, but solution elements such as Check Point’s Secure Domain Logon (which uses a “shim GINA” to establish a VPN connection to a corporate internal network before Windows authentication credentials are actually passed through from the XP GINA) both make PKI and smart-card authentication feasible and allow full integration of most types of mobile clients.

As the above hints at, the goal of a mobile solution must be to extend the corporate perimeter without sacrificing any security or usability, something which I believe is entirely doable and which, in fact, we’ve gotten nicely working on a number of occasions. However, as important as the integrity and security of a given laptop, are the maintenance of anonymity and discretion, and the manageability of a given workstation. Neither the laptop nor a user’s regular everyday actions should give any clues as to the provenance of a laptop, and in no way should compromise of a laptop construe a threat to the integrity of data on the laptop or corporate infrastructure.

In Part II, I’ll discuss individual elements of such a solution.

Posted by john at 8:10 pm

SOMAP -- Open Source Risk Management

Best Practices, Risk Assessment No Responses »
Nov 252006

I recently stumbled onto the Security Officers Management & Analysis Project and thought I’d share. It’s an attempt to create a community-supported risk analysis processes and best practices repository, and a pretty cool idea at that.

The handbook is currently in version 1.0, downloadable from the site, although some of the other resources (risk analysis guide, repository) are in development. The SOBF (Security Officer’s Best Friend) — a risk reporting and analysis tool is also in beta, but looks to be nearly usable. I am going to have a closer look at this to see how it can work together with more technology-specific risk analysis tools like Symantec’s, or with methods such as CERT’s OCTAVE. As it stands, it might be an interesting start for companies who’re out to build their own custom tools and methodologies anyway.

I hope this doesn’t go the way that the OpenCA/OpenPKI project did a while ago (published a handbook that was a great start, but stagnated for a long time, although there seems to have been some work going on recently.) Check it out.

Edit: Adrian Wiesmann from SOMAP just wrote me a nice note to tell me that they’re working on the second version of SOBF, and are looking for a project manager in Switzerland as of present (25.11.2006.) “To make it less possible that the project stops again right after starting, we are actively looking for a project manager which would coordinate the contributors, manage timelines and subprojects.” So if you’re interested, drop them a line via their website.

Posted by john at 3:45 pm

Windows Vista Security Guide, Medical Computers

Architecture & Design, Best Practices No Responses »
Nov 132006

In a brief follow-up to yesterday, I stumbled on Microsoft’s Windows Vista Security Guide, released November 8.

Interestingly, the thing differentiates between regular workstations (ECs or Enterprise Clients) and “other, more secure stuff” (SSLF — Specialized Security, Limited Functionality.) I guess they’ve figured out that a lot of outfits use XP for “non-end user” types of things *cough* medical data stations *cough*. They do mention that SSLF assumes a Vista-only environment (i.e. no mixed XP-Vista-2000-whatever networks.)

Some customer sites incorporate multiple vendor platforms; even vendors will probably want to manage multiple platform types. That is, assuming someone comes up with a way to reliably do this via central domain management — one of the problems of medical / IVD device maintenance is that you have a vast variety of customer IT operations policies regarding external vendors. Remember that some of these guys are the ones screaming about adding medical devices (data stations, laboratory information servers, etc.) operated and maintained by vendors’ support staff to their own NT domains.
Some problems I can see right off the top:

  • BitLocker/VEK usage expects either a TPM to be present, or the user to insert/remove an external USB device at boot (at risk of overwriting the startup key)
  • As mentioned previously, good luck on he homogenous OS environment
  • The domain management structure assumes a sensibly laid out directory structure before you actually start deploying systems and policies. That’s going to be difficult with such a wide variety of environments and machines, see above

To be fair, Microsoft seems to have put a bit of thought into user privilege separation, which will be of use in the maintenance of system integrity with different levels of user access (developers, field service staff, users, etc.) I’m not sure how I feel about Defender; Microsoft itself says that it needs to be checked against other security components for interoperability. That’s going to be interesting in the face of medical IT’s main problems, which is the issue of managing large numbers of diverse hosts on different network. It’s still pattern-based to a large degree, so how that works remains to be seen. And unfortunately, Vista’s firewall doesn’t seem to have made much progress towards being an easily configurable stateful (ipchains-style) firewall that secures against outgoing crap as much as against incoming badness.

Looking more closely at the SSLF baseline, it resembles the sort of “hardening” that frustrated engineers have been doing with XP-abused-as-anything-besides-a-workstation for years. Disabling a bunch of services and providing pre-defined GPOs is a good start, but one that will need auditing itself to make sure it’s not breaking anything.

One of my major dislikes of XP hardening scripts & packages so far is that there seems to be no concise listing anywhere of registry keys that should be disabled or changed, at least when I wrote my last hardening package about 10 months ago. This includes information on what all security-relevant keys do, and which components rely on them. That doesn’t appear to have changed, and will continue to make things difficult for anyone wanting a closer look at how Vista is hardened, including by the pre-defined MS policies. At this point, I think it’s a good idea to continue to treat Windows boxes as something that needs to be protected from remote bad mojo by physically distinct, external network security products.

Posted by john at 4:06 pm

User Friendliness & Authentication

Authentication, Best Practices No Responses »
Nov 112006

Users are the weakest link of any security solution that is not directly connected to a company network and thus under constant control and surveillance. Most mobile users will not be experienced IT staff with a high degree of technical knowledge, but managers, consultants, investment advisors and other professionals who expect a solution to “just work”. It is safe to say that these users will accept and work with a platform that follows two general guidelines, submitted for your approval:

No unreasonable complications are thrown in the way of the user’s work in the name of security

An excessively strict password policy is a classic example of such a hurdle. Security requirements that inconvenience users, such as having to repeatedly enter long pass phrases, tend to desensitize individuals to the need for information security. Users generally accept and understand the need to comply with security policies. However, at some point many employees start refusing to follow procedures that interfere with their productivity, and write down passwords or take sensitive data home on USB pen drives.

Users are confronted with familiar terminology and interfaces

Most of us prefer to work in familiar surroundings, using tools we are familiar with. Almost all technical experts have been confronted by staff from “the business” wanting to learn as little as possible about new interfaces and functionalities. A typical business computer user is accustomed to certain interface “memes”, and will usually think in terms of these. John’s girlfriend, for example, is a strategy consultant; while she is a highly intelligent and experienced professional (hi!), she understandably prefers to work with the tools that she is accustomed to, which are widely used in her field, and expects a certain look and feel from her laptop and applications.

Users seem generally willing to work with security measures if they are integrated into their accustomed working environment, and not made excessively difficult. The following is an example contrasting technical ideals of stereotypical users and security engineers:

User ideal: Single sign-on, one easy-to-use authentication medium for everything

Why not: Security breach of all assets if SSO credentials become compromised, difficulty of administration

Security pro’s ideal: Different, strong passwords for all applications, frequently expired, users will remember everything

Why not: Users will not remember anything, will write down passwords

In my experience, two-factor authentication, such as an RSA SecurID card or a Smart Card combined with a PIN code, is an example of an acceptable compromise for this particular problem,. These can be made to use the Microsoft Windows GINA, or any number of other authentication prompts that use a “look and feel” that users are comfortable with, such as the CheckPoint VPN-1 authentication prompt.

Windows Smart Card GINA

Users “get” this

Furthermore, I’ve have seen that multiple authentication steps are accepted if they use a “single set of credentials” (as opposed to single sign-on.) If a user is repeatedly required to enter a PIN code that authenticates a smart card-stored certificate or SecurID card, for access to various applications or data, the task of entering credentials becomes nearly mechanical and is not nearly as odious as the use of multiple passwords. A PIN code is far easier for users to remember than a password, and as an element of two-factor as opposed to single-factor authentication, more secure overall.

Posted by john at 8:46 pm
Older Entries
© 2010 Chakraborty Software Suffusion WordPress theme by Sayontan Sinha