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.

Max Moser just sent an announcement about the release of BackTrack 4 to the ZOG security list.  I’ve played with earlier versions of this, and while at the time it didn’t boot well on my ThinkPad X21 (works fine meanwhile) it’s a pretty awesome toy.  I can’t imagine that you’d want to hide a powered-down device in someone’s network and then PXEBoot it… =)

The Remote Exploit Development Team is happy to announce the release of BackTrack 4 Beta.
We have taken huge conceptual leaps with BackTrack 4, and have some new and exciting features.
The most significant of these changes is our expansion from the realm of a Pentesting LiveCD towards a full blown “Distribution”.

Now based on Debian core packages and utilizing the Ubuntu software repositories, BackTrack 4 can be upgraded in case of update. When syncing with our BackTrack repositories, you will regularly get security tool updates soon after they are released.

Some of the new features include:

* Kernel 2.6.28.1 with better hardware support.

* Native support for Pico e12 and e16 cards is now fully functional, making BackTrack the first pentesting distro to fully utilize these awesome tiny machines.

* Support for PXE Boot – Boot BackTrack over the network with PXE supported cards!

* SAINT EXPLOIT – kindly provided by SAINT corporation for our users with a limited number of free IPs.

* MALTEGO – The guys over at Paterva did outstanding work with Maltego 2.0.2 – which is featured in BackTrack as a community edition.

* The latest mac80211 wireless injection pacthes are applied, with several custom patches for rtl8187 injection speed enhancements. Wireless injection support has never been so broad and functional.

* Unicornscan – Fully functional with postgress logging support and a web front end.

* RFID support

* Pyrit CUDA support…

* New and updated tools – the list is endless!

With all these changes, PLUS the usual goodies and surprises we have in BackTrack, we are truly excited about this new release.

We consider the Beta to be stable and usable. Some tools were kept back from this version, and will be soon added to the repositories.

Get it at http://www.remote-exploit.org

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.

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.

Between the two of us, Arjo and I have helped design, set up or run on the order of a dozen public key infrastructures (PKIs). Looking back, not a single one of these was not somehow embroiled in administrative or organizational infighting, bogged down by uncooperative management, or less-than-optimally functional due to design decisions taken for some sort of political reason. To use a colleague’s phrase, these things seem to attract managers like FOS — flies on you-know-what.

We were recently asked to put together a requirements paper for a PKI that was being re-engineered from the ground up. It occurred to me that this might actually be a stellar opportunity to help a client get things right from the start. So, why do we always get bogged down in PKI-related organizational or management issues?

Obviously, the PKI’s main purpose is management of digital certificates for persons, organizations and technical entities. Certificate keys fall into three general categories, which I’ll use Entrust nomenclature to describe: encryption (obvious enough), signing (you can be sure that what you got from me is what I intended to give you) and non-repudiation (you can be sure that I cannot disavow what I gave you.) So, let’s look at what you might actually use these for:

  • User authentication (such as web sites or to workstations via smart cards)
  • Email and file encryption
  • Secure key exchange (e.g. for phase II IPSEC negotiation) between devices
  • Source code, binary and other data signing (e.g. financial transaction information)

Why is this important? Two reasons: first, your certificate templates, which govern the formats of the certificates and their usage, depend on what you intend to do with certificates. In most certificates, for example, there is a key usage flag (a hex value) that is used for this.

Second, and more importantly, your LDAP structure must reflect you organizational structure, certificate usage and a number of other factors from the outset. This is usually the largest bone of contention in PKI design; the classic example is the Jane Doe who marries Bob Smith and changes her last name. So a distinguished name (DN) like C=Albania,O=Bob’s Widgets Inc,OU=Research,CN=Jane Doe is now kind of messy. This can be dealt with by using a friendly name, but you get the idea. Changes in requirements for LDAP attributes and DN structure affect other areas, like host naming, validity of signing and encryption keys, and and and. It gets even more fun when you start doing things like cross-certification, setting up a metadirectory for multiple directories, or integrating existing directory structures.

The upshot of all this is that a PKI affects all aspects of an enterprise that are in some way involved in authentication, security, encryption, verification of data integrity, etc. — and it has to pretty much be done right from the outset, or you run into problems of application integration, user acceptance and overall cost. We know of several directory projects that had their scope drastically cut down after they were built, when it was discovered that they simply wouldn’t work for some of what they were intended for; someone obviously hadn’t done their homework.

Most tragically, sometimes design decisions are taken or changed late in the development phase. I will recount one infamous experience of a client who, based on a few casual observations our team made, called a stakeholder meeting consisting of a room full of 35 people shouting at each other, and reversed his entire enterprise directory strategy _twice_ in the course of two hours. We’d done the underlying design and recommended a certain set of project technology several months previously, but were ignored due to political reasons. In this meeting, our group just tried to remain rational and calm, and to give information when prompted, but in the end we realized there was just nothing to be done and snuck out. It was telling that nobody noticed.

Probably, everyone who’s affected will want a piece of the discussion, and we all know how well design by committee works. Many managers also seem naturally threatened by (or nervous about) any technology that effects a lot of blanket organizational and procedural change — a perfect categorization of an enterprise PKI. It doesn’t help that such products sometimes carry the stigma of taking away autonomy from other groups; at some level, any infrastructure component using PKI certificate must follow certain standards and procedures, there’s just no way around that. This is often seen as a loss of self-determination, or it may require technical effort, and who’s going to pay for that?

So, how does one deal effectively with this? A lot of good PKI design practice involves some pretty common-sense elements:

  • A knowledgeable, strong project manager who can organize management buy-in and support
  • A small design team who’ve done this before and have a clue what they’re doing (good luck!)
  • Individual discussions with potential stakeholders about what they want and how their concerns can be addressed
  • A _lot_ of time spent on research and design — use the “hire a 6-year-old to spot any obvious flaws in your plan” model liberally here
  • A clear idea of budget responsibilities in PKI deployment — but not to the end that every affected team will try to pawn off even minor changes on the PKI budget

And last but defnitely not least, a really good LDAP guy, you won’t regret it.

p.s.:  If you’re interested in reading more about non-repudiation, including how it differs from the usual technical usage of “signing”, have a look at Non-Repudiation in the Digital Environment.

Standard issued by the Clinical Laboratory Standards Institute (CLSI), document ID “Auto-11P”. One of several recent attempts to specify standards for IT security in medical devices. Covers network security, separation of privileges, development best practices, as well as review techniques. Many of its elements are very basic (e.g. explanations of encryption and authentication technology, what is a firewall, etc.) and rely on common sense, but then again the medical and IVD fields are about 10 years behind the technology curve as security is concerned.

The doc is targeted at 3 sensible groups; vendors (i.e. R&D and support staff), end-users and customer IT managers. There is provision made for the idea of protecting against data theft, although the prime issue in this area is data corruption by malware and other attacks. As you are probably aware, the main problem facing medical device manufacturers is the inability to consistently patch systems to respond to newly discovered threats and vulnerabilities; every “change” to the nature of a system requires a complex and expensive re-validation process.

Naturally, the solution to this is “don’t develop purely oriented towards functionality”. In plain English, don’t scrounge around for technology that just happens to be available, such as Windows XP, without proper design criteria and a fundamental evaluation and risk assessment process (what will the long-term cost be due to the fact that we used crappy technology to start out with…) I’m hoping that the suggestions and requirements in this doc will narrow down the solutions chosen for development platforms such as diagnostic data stations to technologies considered secure and reliable by other industries–which have more experience in secure development.

Unfortunately, as it’s a commercial document I can’t post the text here, but it is available at http://webstore.ansi.org/ansidocstore/dept.asp?dept_id=57 and via CD-ROM subscription from CLSI.

From the press release at http://www.clsi.org:
“Newly proposed Clinical and Laboratory Standards Institute (CLSI, formerly NCCLS) document IT Security of In Vitro Diagnostic Instruments and Software Systems; Proposed Standard (AUTO11-P) specifies technical and operational requirements, as well as technical implementation procedures related to security of IVD systems (devices, analytical instruments, data management systems, etc.) installed at a healthcare organization. This document provides a framework for communication of IT security issues between the IVD system vendor and the healthcare organization.”

Forwarded by a colleague, supposedly found on a Russian spyware forum a little while ago. This is as close to a formal software requirements doc as I’ve seen for an exploit / trojan. It describes in reasonably structured detail the elements required for development of a spam botnet trojan.

Click here to download

© 2010 Chakraborty Software Suffusion WordPress theme by Sayontan Sinha