I had high hopes for the work of the UK parliamentary-industry group EURIM in developing the foundations of Information Governance. With no less than five work streams attended by leading, experienced practitioners, I expected some quality deliverables. So I was a little disappointed with this animated storyboard on the subject, which strikes me as abstract, content-free and dumbed-down. We can do better than this.
May 2009 Archives
US President Barack Obama's speech on plans to secure American cyber infrastructure is an encouraging start for developing the long-overdue capabilities that the West needs to safeguard its essential services. But it only scratches the surface of the emerging information security problem space.
Operational services and infrastructure are the tip of an information age iceberg of intellectual assets that need to be safeguarded from increasingly sophisticated security threats. As time goes by, we will place a higher value on the knowledge and relationships that create our longer-term, national wealth. Visibility of the solution space always starts with issues of availability, followed by confidentiality, and lastly integrity. But the most serious long-term issues are those associated with the subtle manipulation of intangible, intellectual assets, such as trust, reputation and influence.
As we've recently seen in the UK, loss of trust in an institution can cause more serious impact than an outage of services. It's a much harder set of risks to manage. But that's the bigger challenge that governments need to recognise and address.
This month's edition of Information Age magazine carries an insightful review of my book "Managing the Human Factor in Information Security". Information Age is an excellent magazine, which for many years has encouraged innovation, excellence and networking across the UK IT sector. It's a privilege to be reviewed in it.
Back in 2003, Gartner declared that intrusion detection systems were a market failure and would be obsolete by 2005.
Six years and 3.7 million downloads later, Sourcefire is celebrating the 10th anniversary of Snort, the de facto standard for intrusion prevention and one of the world's most popular network security technologies. With 244,000 registered users, including 80% of Fortune 100 companies, Snort demonstrates that intrusion detection is far from obsolete.
It couldn't have happened to a nicer guy. Here's a nice shot of Marty Roesch, founder of Sourcefire and Snort, celebrating their tenth anniversary. I wish him another ten years of success. His products are excellent.
The Jericho Forum and the Cloud Security Alliance announced today that they're working together to promote best practices for secure collaboration in the cloud. It's encouraging news as both groups have been developing models and guidance on cloud computing security.
Cloud computing offers substantial business benefits and, given enough effort, the risks can be mitigated to an acceptable level. But a lot of the benefits of cloud computing will be lost if organisations decide to adopt different security models for expressing their requirements. A common approach to security is the best way forward.
Both groups share a common goal of helping business to understand the opportunity posed by cloud computing and encouraging common and secure cloud practices. And both have recently published initial guidelines for cloud computing. The Jericho Forum is committed to open standards and has no political or commercial baggage, so there's less risk of vendor lock-in in following their advice.
The current crisis of public confidence in UK Parliament, triggered by the publication of MPs' expenses records, demonstrates three interesting and very important lessons of crisis management. They are worth noting, as they play a part in all major crises.
Firstly, there is the unexpected, unprecedented level of public and media rage. As Dr. Peter Sandman, a long-standing expert on risk communications once put it: "The engine of risk response is outrage". The need to manage extreme reactions should always be taken into account when planning any crisis response.
Secondly, there is the invisible culture that surrounds the crisis organisation, blinding them from the true nature of the crisis. They cannot see anything wrong in their long-standing practices. Good crisis management requires an objective perspective. The crisis team needs to see events with the eyes of an outsider.
Thirdly, there is the natural tendency to focus on the trigger of the crisis, rather than the underlying cause. The legality of MPs' expenses claims, and the rules governing them, are not the real issues. It's the perception of greed that outrages the public. And that demands a much more radical response.
Unfortunately when organisations are in crisis, they tend to operate on gut instinct guided by wishful thinking, instead of logic and expectation of the worst possible outcome. It's more comfortable to aim to muddle through, rather than confront difficult issues. But a crisis is a major turning point. Things will never the same again.
The Hall of Fame presentations given by Paul Dorey and myself are now available on the Infosecurity Europe web site. Recordings of these sessions and podcast interviews will also be available shortly.
This site is still worth checking out long after the event as new content and discussions appears regularly.
Each week we get closer to a business and social cyberspace dominated by spin, FUD and disinformation. It's an inevitable consequence of the power of large-scale information and social networks.
Recent incidents confirm this trend. The latest one, reported in The Register, is a viral infection that redirects Google search results. The goal of the malware appears to be an attempt to siphon money away from Google's highly profitable advertising franchises. It's a sign of the times. Just imagine what we'll be seeing a decade from now.
Bruce Schneier's blog highlights reports of an alleged recent break in by hackers to a Virginia State Web site used by pharmacists to track prescription drug abuse. The hackers were reported to have deleted records on more than 8 million patients and replaced the site's homepage with a ransom note demanding $10 million for the return of the records. Interestingly, the back-ups were reported to have also gone missing.
We can expect to see more of this type of incident. I've been pointing out for some years that security is about to enter a new phase. In fact it's the third and arguably the most significant phase of information security. I call it the "age of integrity". If you take a step back and consider those three pillars of information security - confidentiality, integrity and availability - you might notice that at any one time they don't have equal visibility. Consequently they don't receive the same degree of attention. In fact, there's a historical pattern to this, and it affects both the problem space and the solution space.
Availability is the first thing people notice. Fallback and back-up were the focus of most commercial security functions back in the 1970s and 1980s. Only national security and retail banking organisations cared about confidentiality. Business continuity was the big thing when e-Business took off in the late 1990s. By the turn of the century, denial-of-service attacks were the most worrying threat to online services. But availability is easy to address; expensive perhaps, but easy just the same. You can quickly bring services back after an outage. You may have lost some business, but there's little permanent damage.
Confidentiality is the second strand that security managers address. Ten years ago, you couldn't sell laptop encryption. Now everyone's buying it. In fact people have been stealing and losing laptops for years, but we've only just become paranoid about it, even though a loss of confidentiality is much, much scarier than a service outage. Even a single data breach can cause massive reputation damage, generating citizen outrage on an unprecedented scale.
Now consider a loss of integrity. It's the last thing that security managers think about, but by far the scariest. Whether the cause is deliberate or accidental, it undermines business confidence. In the most extreme cases it can permanently reduce the value of the data and business services. But even small amounts of damage can be hard to recover from, especially if you don't know the extent of the damage. And we're all vulnerable to this risk.
In fact data integrity is where confidentiality was five years ago. It will take a few more years to emerge as by far the biggest threat to future business. But it will arrive with a vengeance. Just as confidentiality was not taken seriously prior to the TK Maxx and HMRC data breaches, so data integrity will not be addressed until a big incident highlights the danger. It's a ticking time-bomb waiting to explode.
If Kit Cameron can come up with a set of laws of identity when arguably there aren't any, then the least I can do is have a stab at setting out some principles of good security architecture. If nothing else, it might stimulate some much-needed debate on how to best exploit a double-edged sword that's equally capable of adding value or creating confusion. Here are my suggestions.
1. Set clear, defined objectives: A model is a means to an end, not an end in itself. Start by defining why you need it and who will use it. Only then can you determine the scope, size, content and presentation. Drivers and benefits can vary widely. They can help organize work, standardize activities, demonstrate compliance, act as a sales device for a vendor, or simply serve as a therapeutic exercise for the compiler. Never lose sight of the original purpose and audience. Otherwise it will not be fit for purpose.
2. Small is beautiful: Whatever you're using it for, the whole point of using a model is to define and communicate a set of selected, relevant facts to a specific group of users. Unnecessary detail should be filtered out or hidden from the sight of the user. The information conveyed should be as brief and simple as possible to meet the objectives of the model.
3. One size does not fit all: Modern security management requires a range of different models, each serving a different purpose. They can be used to communicate or assess controls, responsibilities, activities, services, project tasks or specifications. Different models can be linked or combined but the contents will not map together neatly. A model designed for one particular purpose or audience might not be appropriate for another, though there are always exceptions.
4. Call it anything you like: It doesn't matter much whether you use the term "model", "framework", "architecture", "method" or anything else, though some terms are stickier than others. Architecture, for example, sounds grandiose and suggests a blueprint for building something. But it's mainly just a matter of taste. What really counts is how it is perceived by users and other stakeholders.
5. There is no set format: I've designed, commissioned and used many different types of security framework. They have taken the form of word documents, glossy publications, wall charts, slide packs, databases, software, hypertext and pseudocode. Each approach offers different benefits. What works best for one audience might not translate to another.
6. Incompleteness is good: Security frameworks are more fragmented in their coverage than business, data and IT architectures. It's because the security solution space is sparse, volatile and lags behind a problem space that's largely hidden and unpredictable. If you end up with a complete, balanced, filled-in matrix, then you've either excluded a good number of unsolved issues or incorporated a large degree of worthless padding.
7. Steal with caution: Copying or adapting other people's ideas and material is a useful shortcut if the material is sufficiently general and designed for a similar audience. But be warned: organizations vary widely in their tastes, risk profile and governance style. What works in one enterprise for one particular purpose at one particular time, might not translate to other situations.
8. Security is event driven: Security requirements are primarily driven by events, exposures and compliance demands, rather than business needs. Business goals and risk appetites will of course shape all decisions on countermeasures and priorities. But controls and requirements cannot be directly derived from business, data or technology models.
9. Cosmetics and politics matter: The top-level presentation of any model is not critical to the content and is best determined by cosmetic and political considerations. Ease of navigation by the intended user is also an important consideration. Essentially, if it doesn't look appealing or reflect the politics of organization it won't be accepted. And if it's difficult to navigate it won't get used.
10. Design with the future in mind: The sell-by dates of models or their underlying content can vary widely. Some are highly volatile, others more enduring. Some content can be rendered obsolescent by unanticipated organizational or technological changes. For ease of maintenance, separate fast-changing detail from long-lasting content. And consider the impact of longer-term changes on structures and metadata.
I could of course go on longer, but I think ten suggestions represents about the limit for a memorable set of principles. Any observations?
I've commented a few times already on the use, and misuse, of standards, architectures and other forms of model to help us to manage information security. There are now so many control frameworks, process maturity models and Zachman-style architectures appearing on the scene that we're in danger of drowning in a sea of frameworks.
"Give me a framework and I'm free" was a quotation I vaguely remember from my time at Cass Business School. We might equally add "Give me too many frameworks and I'm lost". In fact, as more and more people enter the security profession, it's inevitable that yet more models will be developed. It would be a nice aspiration to imagine that we could all agree on one, single, standard framework. But in practice they don't serve the same purpose, so it's natural that they will vary in style, terminology and perspective. And the richness of the solution space suggests that a single, universal framework would be impossibly broad and complex to manage. We all know that it's far better to eat a barbecued elephant in bite-size pieces.
Many models share common definitions and concepts, but that doesn't always help the situation. To paraphrase Eric Morecambe, they use "all the right words but not necessarily in the right order". We're faced with a rag bag of overlapping, inconsistent and sometimes contradictory tools. And that won't go away. It's just part and parcel of the rich tapestry of contemporary security management. The missing link is the lack of accepted wisdom on where we should start, what we should build ourselves and what we should steal or adapt from others.
To be fair, frameworks are very useful devices. They help us to define, structure, and communicate ideas and requirements. And their potential is surprisingly broad. We can develop different structures at varying levels of abstraction to structure policies, processes, standards, principles, commandments, risks, activities, services, compliance requirements, projects or technologies. In fact, any interesting set of artifacts you might wish to model for one purpose or another.
We can call them models, frameworks, architectures or management systems. We can present them as shapes, tables, guidelines, standards or position papers. They can be general or specific, and flexible or prescriptive. They can describe who does what, when, where or how. They can represent long range aspirations or short term goals. They can define evolutionary steps or methodologies, or just serve as a snapshot of the current situation.
Each approach is generally designed to serve a particular purpose or audience. Some are primarily for the benefit of the developers. Some will save significant time and money. Others will turn out to be an expensive drain and distraction. A small number of good frameworks will survive the test of time, enduring for a decade or more. A lot more will be consigned to the scrapheap, quickly sinking without trace after years of patient development. And one or two will grow into powerful vehicles for selling related products and services.
What we really need is not more frameworks, but better guidance on how to use them. we need to know which models to pick, what to use them for, and how best to develop and exploit them. My book Managing the Human Factor in Information Security provides a few suggestions in this area. But more guidance is needed. So I've decided that over the next few blog postings I'll try to set out some suggestions on how best to surf this expanding ocean of frameworks, whilst avoiding the many sharks that lurk in wait for the inexperienced practitioner.
-- Advertisement --
-- Advertisement --