We had an email recently from an observer "curious as to why the webcam that was inside the shop/bar is no longer there, or at least, functional". The email was from the Defense Threat Reduction Agency in the United States.

When we replied that it was simply a short term technical problem, we asked why on earth they could be interested in the comings and goings of a small Distillery off the West Coast of Scotland. Were there secret manoeuvres taking place in Loch Indaal, or even a threat of terrorists infiltrating the mainland via Islay?

The answer we received was even more surreal. Evidently the mission of the DTRA is to safeguard the US and its allies from weapons of mass destruction -chemical, biological, radiological, nuclear and high explosives. The department which contacted the Distillery deals with the implementation of the Chemical Weapons Convention, going to sites to verify treaty compliance. Funnily enough chemical weapon processes look very similar to the distilling process and as part of training there is a visit to a brewery for familiarization with reactors, batch processors and evaporators. As they said, it just goes to show how "tweaks" to the process flow or equipment, can create something very pleasant (whisky) or deadly (chemical weapons).

As they say: "In the post-Cold War environment, a unified, consistent approach to deterring, reducing and countering weapons of mass destruction is essential to maintaining our national security. Under DTRA, Department of Defense resources, expertise and capabilities are combined to ensure the United States remains ready and able to address the present and future WMD threat. We perform four essential functions to accomplish our mission: combat support, technology development, threat control and threat reduction. These functions form the basis for how we are organized and our daily activities. Together, they enable us to reduce the physical and psychological terror of weapons of mass destruction, thereby enhancing the security of the world's citizens. At the dawn of the 21st century, no other task is as challenging or demanding".

He is urging young entrepreneurs and engineers to stop making some of  the sillier software that lets Facebook users throw virtual sheep at  their friends or download virtual beer on iPhones, and instead start  making a real difference in the world.

He says it's not just the right thing to do, but also the smart thing  to do -- especially as the credit crunch spreads to Silicon Valley,  venture financing becomes scarce and start-ups have to retrench.

When this grizzled, 54-year-old tech-industry veteran talks, Silicon  Valley tends to listen, if only to argue with him.

He is urging young entrepreneurs and engineers to stop making some of  
the sillier software that lets Facebook users throw virtual sheep at  
their friends or download virtual beer on iPhones, and instead start  
making a real difference in the world.

He says it's not just the right thing to do, but also the smart thing  
to do -- especially as the credit crunch spreads to Silicon Valley,  
venture financing becomes scarce and start-ups have to retrench.

When this grizzled, 54-year-old tech-industry veteran talks, Silicon  
Valley tends to listen, if only to argue with him.

The FBI almost certainly closed DarkMarket in preparation for a global wave of arrests that will unfold in the next month or so. The site was likely shuttered to avoid an Agatha Christie scenario in which a diminishing pool of cybercrooks are free to speculate about why they’re disappearing one-by-one like the hapless dinner guests in Ten Little Indians.

How on Earth does that make sense? If they close the market and announce their involvement, now they’ve given up their cover and surely all the hackers already know the FBI is on to them. They can simply move and restart their operations somewhere else.

Read the whole Wired article here.

Up first is a new MacBook Pro, with a buttonless trackpad, full glass screen (like the iMac), and all ports migrated to one side of the machine. The new buttonless trackpad adopts the iPhone’s multitouch functionality, offering a glass surface area that is both 39 percent larger than previous trackpads and allows for gestures involving up to four fingers. The new construction features an LED-backlit display, next-gen Nvidia GeForce 9400M and 9600M graphics with 512MB of GDDR3 RAM (and the ability to run them in Hybrid SLI mode), and a “precision aluminum unibody enclosure” that cuts down on parts costs while offering a much more rigid construction than the current aluminum design.

Some of the changes are great — more surface area on the trackpad and stronger construction–who can fault them for that? However, why on earth would they want to move all ports to one side? It’s really useful to bea ble to plug some things (like USB ports) from both sides, and honestly they need more than just 2 USB ports, so I’m sad to see that wasn’t updated.

The other great ergonomic change that could be made on the large MacBooks would be to move the speakers (currently at either side of the keyboard) to the center, and separate the keyboard sections to allow some space between your hands. But Apple might anticipate that this is a change that would be badly received by some users and that it can easily be corrected using a special ergonomic keyboard–everyone with a laptop should be using an external keyboard regularly anyway.

One of the main problems in counterterrorism today is that there are so many people and vehicles, and so much data and material, moving through globalization's myriad networks that it seems virtually impossible to track it all effectively. Nowhere has this problem been more acute than on the high seas.

In 2006, Adm. Harry Ulrich, then U.S. commander of NATO Naval Forces Europe, decided to do something about it. Despite having virtually no resources, his dream was to transpose the global air-traffic control system onto sea traffic.

Worldwide, aircraft are transparent, because they're all required to carry an identification beacon that allows them to be tracked leaving and entering airports, and monitored between airports, by a global network of sensors. Act suspiciously and somebody's fighter aircraft will soon be on your tail.

No such pervasive system currently exists globally for maritime traffic. While bigger ships carry an ID beacon similar to aircraft, without a shared monitoring network, that's like tracking only selected commercial jets and giving everyone else a pass.
So Ulrich, upon taking command, asked a simple question: "If we can do that in the air, why can't we do it on the sea?" He made a point of pioneering his sea-traffic-control effort first inside the Mediterranean, where NATO's southern naval forces have historically been concentrated, but his real target was waters off Africa -- the most ungoverned maritime space in the world.

Ulrich knew the U. S. Navy couldn't do it alone, much less bring Africa's meager coast-guard-like navies up to snuff so they could do it on their own. So he quickly created a network of assets -- both public and private -- to manage that space, modeling his monitoring system on international air-traffic control.

Ulrich began stitching together a network of shore-based sensors ringing the Mediterranean. His naval command then began initial monitoring by tapping into the International Maritime Organization's existing Automated Identification System, transforming NATO's ability to track ship traffic in the Med.

Almost overnight, NATO went from tracking dozens of ships on the Mediterranean to thousands, and instead of getting the data sometimes up to 72 hours late, now the contacts were being tracked in one to five minutes -- to an accuracy within 50 feet on the earth's surface.

When the classic big-firm systems integrators told Ulrich it would be too costly to pull it off, the admiral turned to the Volpe Center in Cambridge, Massachusetts, a U.S. Department of Transportation research center. Instead of hundreds of millions of dollars, Ulrich's initial network cost $900,000. The shore-based receivers are small, roughly the size of a radar dish you might find on a pleasure craft.

The strength of the system is a function of its reach: the more countries join, the larger the shared operational picture. By the time Ulrich retired at the end of 2007, he had enlisted 32 countries throughout the Mediterranean, the North Atlantic, along the west coast of Africa, around the Black Sea, and in the Pacific. Today, the network continues to spread around the planet.

With Ulrich's system in place, local police, coast guards, and border patrols catch most bad guys, obviating American military responses. As Harry told me for an article I wrote about his work in a fall 2007 issue of Esquire, "I don't do defense; I do security. When you talk defense, you talk containment and mutually assured destruction. When you talk security, you talk collaboration and networking. This is the future."

The admiral's legacy program, the Maritime Safety and Security Information System, earned the Volpe Center a prestigious "Innovations in American Government" award this month from Harvard University's Ash Institute for Democratic Governance and Innovation.

Blogger: Dan Blum

With the crisis in financial markets still unfolding, it is important to draw what lessons we can from the experience. Since the roots of the crisis lie in a monumental failure of risk management, it’s important to understand more about what happened, and then draw some parallels to our business risk management and  IT risk management situations.

The risk management failure in the housing market and on Wall Street had multiple interdependent dimensions:

• Mortgage lenders abandoned long standing prudent loan practices. They made too many loans that buyers might not be able to repay. Exotic instruments like ARMs, option ARMs, and interest only loans proliferated. In many cases, all pretense of lending standards were abandoned, so-called “liar loans” approved.
• Capital was grossly over-leveraged. Mortgage lenders and other financial services packaged loans into securities, which they sold to raise capital to support more lending. Real capital reserve requirements to back loans were reduced. Of course, if borrowers could not repay loans, all or parts of the derivative securities would become worthless.
• Risk was aggregated at Fannie Mae, Freddie Mac, and mortgage loan insurance companies. These companies bought or insured some mortgage loans, providing something of a backstop should loans fail. Government sponsored enterprises (GSEs) Fannie and Freddie in turn became over-leveraged and securities that they sold were in turn repackaged in the murky brew of mortgage-backed securities called collateralized debt obligations (CDOs) and other exotic instruments returning generous yields.
• Non-Caveat Emptor. Institutional wealth funds and financial services firms who should have known better bought securities that had been deliberately structured to obfuscate risk. They bought securities they didn’t understand with buried tranches of toxic subprime loans..

It was a great Ponzi scheme – one that kept working as long as housing prices were going up; the recipients of subprime loans could always flip that house to the next buyer. Everyone made money. As Chuck Prince of Citigroup famously put it during a July, 2007 interview: “So long as the music is playing, you’ve got to keep dancing. We’re still dancing.” But one month later, the music stopped. Since then, Citigroup and other financial institutions have taken massive writeoffs with more to come. Wall Street titans like Bear Sterns, Lehman Brothers, Merrill Lynch, and AIG have fallen or been bought out.

What can we learn from this risk management debacle?

As business risk managers and investors, we should ask questions like these:

• Does the executive incentive structure of the company encourage managers to dance around risk? Many Wall Street firms paid senior managers 5 times their salary in bonuses tied to annual growth alone.
• Is the company over-leveraged? Is it borrowing too much money and betting it on ventures with uncertain outcomes?
• Are financial models used for risk management realistic? Earlier, I described the mortgage market of the past few years as a Ponzi scheme, where risk management models must have assumed prices would keep rising. Unlike the dotcom boom whose demise many predicted, very few in the industry foresaw the sharp declines to come in housing prices and sales volumes. Historically, the U.S. housing market has been a steadily rising one, but on the other hand the 2000s saw unprecedented rates of price increases. In reality, what goes up must come down.
• Has your company’s risk council ever performed worst case scenario analysis and built adequate reserves? In the days before economics emerged as a would-be “hard” deterministic science, business leaders may have been more cautious, more aware of and more accepting of uncertainty. Events like the Great Tulip Bubble came once in decades or centuries – not every few years. Note that legendary investor George Soros has proposed a Theory of Reflexivity that, if true, helps explain the recent extremes of boom and bust cycles. This theory holds that market participants model market behaviors based on self-interest, and for a time, their manipulations change the reality of the market – until gravitational forces bring it back to earth. Has the music of ephemeral success played to the backbeat of deterministic-sounding economic models gone to your heads and infected your risk management models?
• Are cost cutting efforts pursued blindly? Outsourcing and other forays into treacherous global waters may be giving away the crown jewels. Smart companies cut costs, but they do it in smart ways. Smart companies think like intelligence agencies as they parcel out work to different partners with varying levels of dependability, and they check on those partners.

Risk management failures can also occur at the more technical level of IT security. As IT risk managers, we might ask questions like these:

• Are the accounting and financial systems your IT department supports under adequate control? As Fred Cohen wrote in one of our documents: “Many companies use computers to manage financial systems, and despite the Sarbanes-Oxley Act (SOX) claims about accounts being properly kept, there are many attacks on financial systems that remain. For example, most of the largest financial systems in the world running on common financial databases do not use double-entry bookkeeping and are thus susceptible to all manner of frauds by insiders.” We find it troubling that a prudent control dating back to the 12th century is going out of style in the name of convenience and cost cutting. Kind of like credit checking became anachronistic during the housing bubble, eh?
• Is the “separation” in your “separation of duty” (SoD) for real? Sure the SOX auditors are looking for SoD, and maybe you have different administrators with different accounts maintaining different systems or functions. But when they say Western civilization may be but one weak password from collapse they’re not lying. Look what happened to Sarah Palin’s email account! Weak and straggly SoD is a problem across all critical IT systems where deperimiterization and server consolidation may be bringing down protective barriers, identity management is weak, and strong process controls (e.g., where two people must sign on, one perform a critical operation such as backbone router reconfiguration, and the second observe) abandoned in the name of expediency.
• Are risks being aggregated to unacceptable levels in centralized control systems? There are many ways that risks aggregate within enterprise IT infrastructures as we pursue automation and cost cutting. Network risks aggregate when centralized domain name system control is implemented. Application risks aggregate when common infrastructure is shared among applications. And enterprises aggregate platform risks when they use low-assurance endpoints, authentication, and directory systems with single sign-on to access large numbers of resources and don’t separate high consequence systems.
• Non-caveat emptor: Has IT security really done the worst case consequence analysis, attack graphs, and vulnerability analysis to know when putting more eggs in a supposedly stronger basket aggregates risks to an unacceptable level? Or are you depending only on vendor claims about some black box appliance equivalent of a risk-obfuscated CDO security? Caveat emptor (buyer beware) again! (The good news is we’ll keep talking about promoting vendor and product rating systems so you don’t have to do all the detailed product analysis yourself, but that’s another post.)

There are many parallels between the monumental risk management failure in the financial markets, and the probable weaknesses in our day to day business risk management and IT risk management. Abandonment of prudent practices for profit; excessive leverage and centralization; ill-constructed risk analysis models; risk obfuscation; and a failure of caveat emptor seem to be common problems. Please take this as a wakeup call to sharpen up the risk management thinking, process, and execution.

OnAir has so far tested their calling/texting-only service on two aircraft--one operated by Air France, one by TAP Portugal--even though RyanAir announced plans that its planes would started being unwired with the service by late 2007. Still no word on that fleet progress.

Qantas will apparently launch cached Web browsing and limited Web email (probably through a proxy) along with instant messaging, with full Internet service coming "later in 2009." This is clearly due to a lack of satellite coverage that was just remediated a few weeks ago (see below). The first plane with limited service, a new A380, should be in flight 20-October-2008.

The Morning Herald seems to overstate the importance and scope of a complaint filed by the union representing American Airlines' flight attendants. The detailed coverage in the U.S. had more to do with the potential for issues, and likely attendants lack of interest in policing yet another media on the plane. Filtering doesn't work, the attendants probably already know, and this may just be a negotiating point with the airline.

On why Qantas is waiting until late 2009? This requires unwinding how OnAir gets its signal.

Aeromobile and OnAir both rely on Inmarsat satellites for their service. Both companies had several years ago staked their futures on the fourth-generation network Inmarsat was to inaugurate with three satellites that would use beamforming to allow precise delivery of nearly 500 Kbps per receiver, with hundreds or thousands of regions being able to be targeted from a single satellite. Inmarsat's third-gen network--don't confuse this with 3G cellular ground-based networks--can deliver about 64 Kbps per channel.

Now, unfortunately, Inmarsat was three years late on launching its trans-Pacific bird. While the company claims 85 percent coverage of the earth and 98 percent coverage of population, there's a big gap over the Pacific that also prevents them from having good overlap between the U.S. and Japan/China/Korea, as well as the southern Pacific, covering Australia. Since the biggest market for long-haul flights would likely be Australia, Japan, and China, traveling trans-Pacific or trans-hemispheric routes, that gap is rather large.

Aeromobile opted to build out a service, deployed only by Emirates airline as far as I can tell, that uses the 3G service since it was available, and most necessary equipment is already installed on most over-water planes. OnAir was waiting for 4G, which has necessitated a long wait, but allowed them to launch in Europe with a seemingly next-generation service. Given that OnAir is controlled by an airline-owned integration firm, SITA, and by Airbus, they're not going anywhere.

Inmarsat finally lofted its third satellite on Baikonur Cosmodrome in Kazakhstan on 19-August-2008, and the launch and separation was reported as successful. Previously, the company has needed up to a year to verify and deploy its 4G satellites. (You can read extremely close coverage of the launch at a Web site devoted to space enthusiasm.)

However, the dirty little secret about Inmarsat's BGAN is that it costs a fortune to heft bandwidth across it. Thus, in-flight broadband over BGAN, if it's ever available, is going to be changed on an extremely high per-MB rate. None of the providers want to say this. This is in contrast to Row 44 (and, once, Connexion by Boeing), which relies on leased Ku-band transponders where they can fix costs and they require high volumes to keep per-bit costs efffectively low.

OnAir's launch of calling on Air France's service involves paying a few euros per minute for calls, which might help you understand what data costs could ultimately run.

I say today is a good day for two reasons:  1.)  BT’s CSO Jill Knesek wrote an article called “Keys to establishing an end-to-end security strategy” which begs some discussion within context, and 2.)  Sara Peters on Twitter last night wanted to know why I thought “risk management” requires more than what most “best practices” around the subject suggest the effort requires.

WHAT SHOULD WE BE REFLECTING ABOUT?

Jill Knesek’s article gives us a rough outline of how to develop a security strategy.  It’s fairly high-level, Pragmatic CSO-ish type stuff.  It gives us a nice outline of

• Get a seat at the table
• Process
• People
• Technology

Nothing earth-shattering there.  But it is a very nice broad CISO-level taxonomy about what we have to reflect on.  The need to reflect is driven by something Jack told me long ago,

“The amount of risk we have is a function of the decisions we made and our ability to execute on them from some point in the past”.

As an Aside:  So Sarah if you’re reading, this quote does much to explain why I said I disagree with much of what our industry calls “risk management”.  We tend to define the process of risk management as essentially a tactical “issue whack-a-mole” exercise. Find the issue.  Analyze the “risk” around the issue.  Fix the issue.  Repeat. This hamster-wheel-of-pain, while sometimes an effective tool for the CISO, is incongruous with addressing root causes (the ability to match a tactical issue to the strategic shortcoming that created the issue is up to the expertise of the analyst or consultant).  It is only Kaizen without (good) Hansei, if you will.

Back to what Jill is writing - the sorts of things we should be reflecting about can be thought of in context of her outline.  Namely:

1. Once you have a seat at the table, what is the nature of that relationship?  Who are you reporting to and what are their concerns? What and how are you reporting and how might that be addressing their concerns?
2. What processes are in place?, How do you know that those are the processes that should be in place? If they are, what kind of job am I doing at those processes?
3. What is the quality of the skills and resources I have from a people perspective, and how do I know if they are adequate?  How do I know that the training they petition me for will effectively reduce organizational risk?
4. Are the Technology solutions I have in place effective, are we managing them effectively, and what sort of States of Knowledge could they provide me with (to make good decisions and execute upon them, from above)?

This, for the CISO, is Hansei.  The continuous management of it is Kaizen.  Not to particularly pick on Jill’s article, but creating a “risk register expressed in ALE” might be fine if you’re trying to explain to the board what your “first 100 days in office” will be like - but these sorts of lists are usually not very strategic in nature, and as such, depending on the outcome of that risk register (and the models used to create it) it might not actually be useful.

WHAT IS NEEDED FOR REFLECTION?

So what is needed for this sort of CISO-level Hansei?

The CISO must understand the

• Current State of Nature

turn that into a

• State of Knowledge

and use that to create a

• State of Wisdom.

CREATING A STATE OF NATURE FOR THE IRM PROGRAM

This Current State of Nature determination be done by applying analytical methods to a program audit.  We must understand questions like,  “What is in that program and how is it structured?”  before we can answer questions about “how (good/bad) are we at managing risk?”

There are many ways to structure an IRM program, but as an example - below is a graphic shared with me by Adrian Seccombe.  For those who know Adrian and the Trust Model - this is classified as “white” so it’s OK for public display and consumption.  But here’s what Adrian is trying to build at a high level:

So regarding Adrian’s program diagram:

1. Is a governance framework.  Think ITIL.
2. Is a risk framework.  Think ISO 27002 using FAIR as an analytical engine.  To be fair (pun) I believe this is really issue management, and it’s a process, but that’s OK.
3. Reg compliance should be self explanatory.  That’s essentially what GRC products do for you.
4. With architecture, I think Adrian is inclined towards TOGAF.
5. Security is the ISMS in place (27001, ISM^3, PCI, whatever…)
6. Are the processes that drive execution
7. Monitor (audit) is creating a State of Nature and Evaluate is creating a State of Knowledge from that State of Nature around items 1-6.

EVALUATE - CREATING A STATE OF KNOWLEDGE ABOUT THE IRM PROGRAM

That evaluate is Hansei/Kaizen.  Evaluation, done effectively, will drive actual organizational risk exposure.  Evaluate will even answer those four questions we raised in the “What Should We Be Reflecting About” section above:

1. Once you have a seat at the table, what is the nature of that relationship?  Who are you reporting to and what are their concerns? What and how are you reporting and how might that be addressing their concerns?
2. What processes are in place?, How do you know that those are the processes that should be in place? If they are, what kind of job am I doing at those processes?
3. What is the quality of the skills and resources I have from a people perspective, and how do I know if they are adequate?
4. Are the Technology solutions I have in place effective, are we managing them effectively, and what sort of States of Wisdom do they provide me with (to make good decisions and execute upon them, from above)?

If we could have a nice metric (or set of metrics) that answers these questions, we might call it something like “My Ability To Manage Risk” or MATMR for short.

GETTING TO A STATE OF WISDOM

What’s then missing is how you create a State of Wisdom around the State of Knowledge developed - your “MATMR” metric.  That is, given the current State of Knowledge - how can I be most effective?  This State of Wisdom requires proper models for what risk is, and what you can do to manage it applied in a probabilistic manner (because we can’t intrinsically *know* the future, we can only say with some degree of certainty what the desired course should be).

So the outcome of Hansei/Kaizen should be to create a State of Wisdom about Risk Management.  This is why reflection must be relentless - because your wisdom must be similarly abundant.

This is no small part of the reason RMI exists, why we build software and help organizations understand the things they do.

First, the most obvious conclusion: people still don't care much about log security; I am saying that since this was BY FAR the least popular of my polls. Only 24 people responded, so everything below is pretty unscientific :-)  A good way to explain it: look at the recent media? Do these people care about their key business data and their customer data security? Nope. So, how on Earth do you make them care about securing their log data?

Second,  it is entirely unsurprising that 83% of respondents want "Authenticated access to log server." In fact, I'd opine that 100% of people want authenticated access to any of their servers :-) But, this was my "red herring" to set the baselines for the rest of the questions... 

However, this is where the buck stops: other security measures are notably less popular.

Third, "Logging all access to logs" is my favorite and I am happy to see it reported as popular. But do you really do it?  Do you log access to log server OR access to actual logs? Think about it... I think a lot of people who do the latter still answered "yes" to this one.

Fourth,  "Reliable / acknowledged network transfer of log data" and "Encryption of log data in transit " are two true "no-brainer" security features; they took the next spot at 45% and 50% of those who answered. They are simple, they are easy, they make  sense - and, obviously, they don't make logs entirely secure so you need to do more. Why only 50%? Where is THE OTHER 50%?!

Fifth, "all things crypto" are below 40%. "Cryptographic hashing of stored logs", "Cryptographic signing of stored log data" and "Encryption of stored log data" all hover at around 30%. I attribute them to general disregard of log security AND reliance on "system security" (separate server, etc) over "data security" measures for log protection.

Finally, I am embarrassed to say that I missed  the obvious security measure "Separate server for logging, not accessible from the Internet;" one of my readers added this using "Other security measures" choice. Indeed, this is a good point - and a good idea to do it. Another option mention there was "Destroy old logs." Amen to that too!

Possibly related posts:

• Top 11 Reasons to Secure and Protect Logs
• All other polls and their analysis