Monday, June 22, 2026

Country Squire station wagon

The Ford Country Squire station wagon is possibly one of the weirdest examples of corporate branding that I have ever encountered.

Our family had one.  We had a lot of cars over the years, and, at one point, latterly, with a fairly large family, we would often have more than one car at a time.  I remember that there was another station wagon that we had at one point, I can't remember what it was.  But we did have a Ford Country Squire station wagon, for a long time, and it was even the car that we had when we took a trip across Canada in Canada's Centennial year.

First of all, there is the issue of the term station wagon, itself.  Before the sport utility vehicle, and before the minivan, the station wagon was the standard American example of the large family car.  But why call it a station wagon?  It certainly has an implication of an agricultural utility vehicle, but really only in Australian parlance.  In the United states, a farm is called a farm or a ranch.  In England it might be called an estate.  But it's only in Australia that a large agricultural spread is referred to as a station.  So why do the Americans refer to a utility vehicle as a station wagon?

And then there is the model name of Country Squire.  There were, of course, other models of station wagon.  Even Ford had other models of station wagon.  But the Country Squire was certainly popular, and possibly the most popular model of station wagon during the station wagon's run as the American family car.  This possibly has to do with the faux wood trim that was added to the sides and rear of the country Squire.  It definitely made it very identifiable.  But why call it a Country Squire?  Yes, I can see the attraction of referring to the country.  A lot of the advertising for such a family vehicle would refer to the ability to travel out into the country for a family vacation, going camping and such.  But why call it a Country *Squire*?  Squire is of course a reference to gentry or minor nobility in Britain.  But it isn't used widely in the United States.  So why brand an American car as a Country Squire?

SF - 3.15.0 - Quality

SF - 3.15.0 - Quality

The whole quality movement probably has to be referred to Walter Deming.

Following the surrender of Japan at the end of the Second World War, the allies wanted to avoid the problems that had followed the surrender of Germany following the First World War.  The fact that Germany was left without assistance, and facing massive war reparations, was certainly a factor in Hitler's rise, the result being the Second World War.  So the allies provided reconstruction aid to Japan following the Second World War.

Walter Deming was a worker from the US Department of Agriculture.  He worked with the Japanese agriculture industry, and particularly in terms of quality control, both in terms of production, and in terms of packing, storing, and distributing of supplies of agricultural products.  His success in this regard caught the attention of other areas of Japanese industry.  He set up training on quality issues for other Japanese industries.  Over the course of a couple of decades, of course, the quality of Japanese goods quality and reliability of Japanese goods reach such heights that they actually threatened American production.  Thus, a couple of decades late, perhaps, American manufacturers and business owners started to realize that they, too, needed to pay attention to quality.

Deming's seminars for American CEOs, which were highly subscribed, didn't just cover quality, but also many issues of management.  One of the points that he made was that Americans, because of their manufacturing success, thought that they knew something about management.  He would point out, in the seminars, that Americans didn't know anything about management on that basis.  They had been on the winning side following a major world war, and therefore, it would have been extremely hard for their businesses not to succeed.

There are a number of different approaches to the quality movement, but they all seem to lead back, at some point, to Walter Deming's ideas.  There is, for example, Total Quality Management, or TQM.  This relies very heavily on the PDCA, or Plan/Do/Check/Act, cycle that Deming instituted.

Six Sigma is another quality movement.  Sigma is a reference to a standard deviation, on the Bell curve.  The point of the Six Sigma movement is to try and improve quality to the extent that there is almost no difference within six standard deviations, and therefore the normal bell curve starts to look more like a spike.

ISO 9000 is the international standard for quality, although, as previously noted, it isn't really the international standard for quality.  It is a standard and structure for discussing how important quality is to you, and what steps you are taking to ensure that your products meet standards of quality and reliability.


Security frameworks (SF) series:
Next: TBA

Friday, June 19, 2026

SF - 3.12.0 - OCTAVE

SF - 3.12.0 - OCTAVE

OCTAVE is definitely a security framework, since it deals specifically with risk management.  Unfortunately it's rather specialized, since it only deals with risk management.  OCTAVE is actually an acronym, standing for Operationally Critical Threat, Asset, and Vulnerability Evaluation.  It was created by Carnegie Mellon university, who also basically gave us the capability maturity model idea.

It is extremely good at determining risk management.  Unfortunately, it is rather over engineered.  Therefore, it is unlikely that OCTAVE will be useful to your company, unless your company has a minimum of about 5,000 employees.

There is a reduced version, known as Allegro (in keeping with the musical theme), which is probably suitable for small or medium-sized businesses.  For those at the smaller end of the small business range, you probably simply want to go with the plan of getting as many people as you can together, thinking of everything that can possibly go wrong, and then figuring out what you're going to do about it.



Security frameworks (SF) series:

Wednesday, June 17, 2026

Redundant

I saw a t-shirt with the slogan "van life culture."

Isn't that redundant?  Doesn't the phrase "van life" imply life*style*?  And doesn't lifestyle imply culture?  So isn't the T-shirt phrase actually "van culture culture?"

SF - 3.09.0 - NIST

SF - 3.09.0 - NIST

NIST is not a framework, but rather simply a reference to the Computer Security Resource Center (http://csrc.nist.gov) of the National Institute of Standards and Technology of the United States government.

It is a truly valuable resource for anyone involved in information security.  I tell classes that I facilitate in the United States that they should check it out since it is their tax dollars at work.  I tell everyone else that it is available to them, free of charge, and it is not even their tax dollars at work.

One of the factors that makes this both an extraordinary valuable resource, and difficult to describe, is that it is constantly updated.  There are a number of older documents and resources that are available on the site, but most of them get updated or replaced fairly regularly.  I used to recommend a document numbered 800-37.  It was one of the early checklists with, yes, roughly 135 items on it.  Subsequently it was replaced by 800-37 version 2, which was a more principle oriented framework, but, unfortunately, to my way of thinking, was less useful.  Valuable, yes, but not as useful as the original had been.  However, most of the material on this site is very valuable, and it covers an extraordinary range of topics.  One of the areas that it covers is looking at tools in the field of forensics.  I was privileged to hear the presentation by the person who did the research, one time, and the depth and comprehensiveness of his research was truly astounding.  If you know what you are doing, and are in court up against someone who is depending upon evidence gained from a disk image, with this knowledge you can rip their case to shreds.

And all of this is available, at no charge to the user.


Security frameworks (SF) series:

1443

I just noticed that the previous post is the 1,443rd that I have made on the blog.

I probably unconciously noted the similarity to 144, a gross, a dozen squared.

But I kind of automatically factored it, finding that it was the product of a hundred and eleven times thirteen (and 37x3x13).

(Probably nobody else except me finds this interesting.)

SF - 3.06.0 - Graphical Management Frameworks

SF - 3.06.0 - Management Frameworks

There are a few business and management oriented frameworks which I would like to discuss together.  First because they are primarily business-oriented frameworks, rather than security oriented frameworks, and secondly because all three of them have a graphical component which makes it easier to discuss when they are visible, or displayed in graphical format.

The first that I would like to mention is the Calder-Moir framework.  This is a kind of a two-dimensional breakdown framework, which also appears to have been influenced by the color wheel.  There is a radial breakdown of topics, with an outer radial break down some setting and breakdown of the original topics.  The inner circle is the conceptual breakdown, most suitable for Board level discussions, while a middle layer breaks down further into management topics, while the outermost layer goes into operational detail, and actually points to a number of other frameworks.


Next is the Balanced Scorecard. The Balanced Scorecard is a kind of a breakdown framework, in that it breaks your business down into four different conceptual areas or categories.  For each of these there is a scorecard, given a something of a further breakdown of topic areas within those logic larger topics.  The point of the balance scorecard, and it is a very interesting one, is that once you have assessed your business in these four categories, you concentrate your efforts on the area where the scorecard gives you the lowest score.  This makes a lot of sense.  Once you have found out where you are weakest, shore up that particular area, rather than concentrating your efforts on areas where you do have a more reasonable score already.


Finally, there is the Zachman Framework.  This is last on the list, but definitely by no means least.  The Zachman Framework is very broadly used and highly regarded in both business and security.  Although there is no particular security identification, other than business management, in the Zachman Framework itself, the Zachman Framework has been modified as the Sherwood Applied Business Security Architecture, or SABSA framework.


The Zachman Framework is a a breakdown framework.  It forms a two-dimensional grid, where one axis looks at different sizes of business units or contexts within your enterprise, and the other axis generally asks the w5 plus h questions: what, who, why, when, where, and how.  The thing is, that when you think about it, and consider it against the phases of system development or project management, with a little re-arrangement you get a very good match.  This makes a lot of sense in terms of a breakdown structure, and it is unsurprising that SABSA has been a successful security architecture based upon it.  Based upon SABSA, and following the advice of a colleague, I have, myself, use the framework to structure planning tools for both business continuity, and incident response, specifically.




Security frameworks (SF) series:

Tuesday, June 16, 2026

SF - 3.03.0 - ITIL

SF - 3.03.0 - ITIL

ITIL is the Information Technology Infrastructure Library.  It is, in fact, an actual library, or, at least, a collection of books.  At one point it had twenty-nine volumes in it, divided into five sections.  One of the books in the library was on security.  It was, generally speaking, a set of principles, setting out a number of management guidelines.  Because of the importance of management to security, there was an obvious connection to ITIL.  Unfortunately, at some point, the security volume of the information technology infrastructure library was discarded.

Initially, the Information Technology Infrastructure Library was an interesting example of how a poorly defined field required a bothersome and arduous certification process.  You could get certification in ITIL, but in order to do so you had to jump through a lot of hoops, and write a number of essays, on various topics, which I suppose would prove that you had read various volumes of the library.  However, particularly given that ITIL eventually helped influence British standard 15000, and ISO 20000, the ITIL has become more defined, and these days the certification process is much easier.


Security frameworks (SF) series:

Trolley problem options

You are the conductor of a trolley.  (For the purposes of this exercise, the conductor is the person who throws the switch selecting which track to take.  No, I don't know how to drive a trolley, and I don't know how a conductor would throw the switch.)

Ahead of you on the track is a switch.  If you do not switch the switch, you will drive over ten people. These ten people are poor.

If you switch the switch, you will drive on an alternate track, and drive over one person.  This one person is wealthy.  Much wealthier than the collective wealth of the ten people on the original track.

Capitalism states that the wealth of the one wealthy person, whether created or inherited/safeguarded, is greater than the wealth of the ten people, and therefore you should drive over the ten people.

(No, I don't know why none of the people will get out of the way.  Maybe they are all female, and have been tied up by Snidely Whiplash.  No, I don't know where the ranch is.)

Socialism states that the needs of the many outweigh the needs of the few, and therefore you should drive over the rich person.

(No, I don't know why the trolley has been designed with no brakes.)

(No, I don't know what the economics or business model would be for a trolley which has no brakes, and therefore has no ability to stop and allow passengers to board or disembark.)

At this point, a student, representing agnosticism, asks how you know that the people on the original track are poor, and that the people on the one person on the alternate track is rich.

For the purposes of the exercise we will posit that you have just been handed a telegram giving you all of this information, and confirming that beside the group of ten people is a priest holding a sign that you can easily read from where you are that says "Y" for yes or "N" for no, and that on the alternate track there is a rabbi standing beside the rich person with a similar set of signs.  This verifies that the information you have been given in the telegram is correct.

(For the purposes of the exercise there is absolutely no significance to the fact that the person who is verifying the identity of the rich person is Jewish, and that the person verifying the identity of a bunch of poor people is Catholic.)

At this point a student in information security points out that this form of authentication of identity is sadly lacking in verification structures and should not be trusted.

Subsequently, a fatalist says that you can avoid the whole problem of choice by simply jumping from the trolley where you are, thus relieving yourself of the responsibility and moral choice, and leaving the fate of all of the people in the hands of either God or random chance.

An American Christian nationalist now asks whether either the rabbi or the priest is black?


(At this point, the instructor has to go and lie down in a cool, dark room for a while ...)

SF - 2.18.0 - Information Security Forum

SF - 2.18.0 - Information Security Forum

Information Security Forum (ISF)‏
Standard of Good Practice for Information Security

The Information Security Forum (ISF)‏ originally set out to create a standard of good practice for information security.  At least they didn't use the term best practice.

The information security forum divided security into five "aspects," that of security management, critical business applications, computer installations, networks, and systems development.  This follows and models three or four of the "domains" of information security originally created by the International Information Systems Security Certification Consortium.

However, the Information Security Forum broke these five "aspects" out into thirty "areas," and (you guessed it) 135 sections.  The security forum can still be found, but these days has devolved into a rather standard sales organization for training and educational materials.


Security frameworks (SF) series:

Monday, June 15, 2026

Review of "Wardriver"

Yesterday, I watched a movie called "Wardriver."  It has taken me at least 24 hours to figure out that the title of the movie is supposed to refer to the practice of wardriving, an occupation of driving (or, very often, walking) around, trying to find wifi hotspots which are either completely unprotected, or for which the protection is weak and easily broken.

It has taken me that long because the practice of wardriving, in reality, is nothing like the activities done in the movie.  War driving is, itself, a derivation of war dialing; an earlier practice whereby you would mass dial a whole bunch of different phone numbers, attempting to find modems, and particularly modems where the login credentials were weak or non-existent.  The practice of both war dialing and war driving was to find systems that you could get access to.  Neither practice was particularly suitable for attacking a specific company or enterprise, or even a particular type of company or enterprise.

The activities taking place in the movie were directed at very specific types of companies.  As a matter of fact, a number of different practices were involved in the movie, including, rather later in the movie, the practice of credit card skimming, which has absolutely nothing to do with connecting to specific systems, or even systems in general.

There may be other technical activities going on in this movie.  Quite frankly, nothing in the movie prompted me to pay particular attention to the technology that was going on or being used, and the movie is, as so many movies are these days, in very dark settings, which makes it difficult to see anyways, and there are activities going on involving text or chat, which are displayed on screen in fonts too small for my aged eyes to read.  Yes, it was a DVD, and I could have stopped and enlarged the text to figure out more of what was going on, but, once again, there was absolutely nothing in the movie that prompted me to want to take that kind of trouble to figure out extra details of what was going on.

Saturday, June 13, 2026

SF - 2.15.0 - Security Blueprints

SF - 2.15.0 - Security Blueprints

Security Blueprints is an interesting and distinctive type of security framework.  It is an interesting combination of a breakdown framework and a checklist framework.  If you remember the mind maps phenomenon, it is kind of a version of that, related to security.  It was popular at about the same time, approximately twenty years ago, and made a bit of a splash because of an association with IBM at the time.

It's a heavily graphical presentation, with individual boxes representing individual offices, and possibly even processes.  It tends to be rather fractal, like a mind map, in that when you open a box, a number of other boxes with different offices or processes also open.


Security frameworks (SF) series:

"Stay Safe" course ...

Girl at the Community Policing table (excitedly): "We took the stay safe course.at school!"
"Me (truly interested): "What did you learn?"
Girl: "Ummm ..."

Friday, June 12, 2026

SF - 2.12.0 - FISMA

SF - 2.12.0 - FISMA

The Federal Information Systems Management Act, or FISMA, is a law in the United States, and therefore only applies to American systems.  It also primarily applies to American government systems.  Its significance to the broader field of information security is that Americans tend to assume that their laws apply to anyone else who is dealing with American companies or government agencies.  I have mentioned the Sarbanes Oxley law, which is an American law, but which contains wording that is similar to those in various other American laws, stating that, if you do significant business with an American company, you are deemed to have accepted that this law applies to you.  The law assumes that you have deemed to have accepted that this law applies to you even if you don't even know that this law exists.

An additional issue with FISMA is that it really only says and specifies that you need to apply appropriate protection to any information management system.  The protection that you need to apply needs to be appropriate to the importance of the information contained within the system.  The details of what particular programs are important, and what the protections for these systems are are related in various additional standards, such as the National Information Assurance Certification and Accreditation Process (NIACAP)‏, the National Institute of Standards and Technology outline ((which tends to also apply to non-government systems), the Defense Information Technology Systems Certification and Accreditation Process (DITSCAP)‏, and Director of Central Intelligence Directive 6/3.


Security frameworks (SF) series:

SF - 2.09.0 - Common Criteria

SF - 2.09.0 - Common Criteria

The Common Criteria for Information Technology Security Evaluation is International Standard ISO 15408, and is generally known and referred to simply as the Common Criteria.  However, it should be noted that it is not a security framework.  It is not even an evaluation standard.  It is a framework for the specification of evaluation, particularly for security products.
 
To explain this oddity, one need only look to ISO 9000 which is the international standard for quality.  Except that it *isn't* the international standard for quality.  It is a framework for discussion about quality and specification of what your company does in terms of quality.  I have discussed this with people who are ISO 9000 certified, and put it to them that it is perfectly possible, according to ISO 9000, to create a specification which states, essentially, that we make shoddy products, and we don't care.  All of them agree that this is perfectly possible, as long as you describe it in the proper format and jargon.

The same thing is possible with regard to the Common Criteria.  In fact, this has basically been proven.  Microsoft certified Windows NT Server, Version 3.5, and, if you actually go through all the details of that specification you will find that it says, essentially, we make a not very secure workstation, and we can verify that as long as you believe everything that we tell you.

Nevertheless, the Common Criteria has created some very valuable materials and even concepts.  One of the concepts is the division between functional security requirements and assurance security requirements.  This is made evident in the fact that the Common Criteria is essentially divided into three parts.  Part one is a general introduction, contains a number of interesting discussions, and is something that I advise everyone to obtain and read.  Part two establishes the idea of the protection profile, which is the description of the secure device or entity which you wish to create or evaluate.  This allows you to specify the functional requirements of the device.  The third part of the Common Criteria is that which is that allows you to establish the assurance requirements for the device under consideration.  It establishes seven evaluation assurance levels, with increasingly rigorous requirements for the assessment and determination of adherence to the protection profile.
 




Security frameworks (SF) series:

Thursday, June 11, 2026

SF - 2.06.0 - COBIT

SF - 2.06.0 - COBIT

Cobit is a certification, primarily intended for those in the information security audit field, created by the organization ISACA (which was formerly the information systems audit and control association, but decided to go with the acronym rather than spelling out the name of the organization).  It was very popular, around twenty years ago, even with those who were not working in the field of audit themselves.

There are approximately 135 items in the Cobit checklist, but they're grouped into four phases or domains.  These phases are planning and organization, acquisition and implementation, delivery and support, and monitoring.  Those who are familiar with the quality control community and standards will recognize the PDCA, or plan/do/check/act structure initiated and proposed by Walter Deming.

An interesting aspect of Cobit is that when you look at it carefully, you will notice that there is almost no technical material involved in the process.  Cobit is primarily concerned with documentation and the ability to prove that the controls that you state are in place are actually in place.


Security frameworks (SF) series:

SF - 2.03.0 - ISO 27000

SF - 2.03.0 - ISO 27000

I suppose I should start the actual frameworks with the ISO 27000 family.  Yes, there is an ISO 27000 standard, but it is actually just a guide to the rest of the ISO 27000 family.  This is a family of security frameworks addressing a huge range, by now, of various aspects of security.

But the ISO 27000 family really started with ISO 27001, and ISO 27002.  And to discuss that, we should really start with British Standard or BS 7799.  There is a British standard for pretty much everything.  There is in fact a British standard cup of tea.  British Standard 7799, originally, was a checklist of approximately 133 items (although it was further broken down into a total of five hundred controls).  As the limitations of checklists became evident, that original British Standard 7799 became BS 7799 part 1, and there was a more principle oriented British Standard 7799 part 2.  This caught the attention of the International Standards Organization, and they created a standard with principle orientation, which was numbered 27001.  However, a lot of people liked the checklist orientation, and so there was subsequently created a 27002 with the 133 component checklist.  So British Standard 7799 part 1 is equivalent to ISO 27002, and British Standard 7799 part 2 is equivalent to ISO 27001.  I hope that is all quite clear.

British standard 7799, and ISO 27000, and ISO 270001 all refer to information security management systems or ISMS.  This is kind of a way to identify people who learned security through either the British Standard or the ISO 27000 family: the reference to ISMS.

As I have mentioned, there is an ISO 27000 standard itself.  This is one of the relatively few standards that you do not have to pay for, since it is an umbrella to the overall standard family and covers ISMS fundamentals and vocabulary.

However, as I say, ISO 27000 is a family.  There are a number of additional standards associated with the family; an implementation guide, guidance on metrics, risk management, dealings with certification agencies, audit, information security governance, critical infrastructure, and dozens of additional topics.



Security frameworks (SF) series:

Wednesday, June 10, 2026

SF - 1.09.0 - weaknesses

SF - 1.09.0 - weaknesses

As previously mentioned, none of these security frameworks can be recommended without reservation.  All of them have weaknesses, and the weaknesses tend to be similar for every security framework.  Keep these weaknesses in mind as you consider the various security frameworks, and consider which one may help you to improve your security posture, in your particular situation.  Remember, at all times, that none of these is perfect.

One of the most common limitations in all security frameworks is that of the limitation of the content of the framework.  Security frameworks are built by people, and people tend to think that what they face, in terms of security protection and vulnerability and threat, is the most important.  No security framework addresses all areas of security.

You would think that the checklist type frameworks have the advantage in this area, since they are grouping lists of security controls, and therefore touch on a wide variety of processes and threats.  However, remember also that those frameworks that concentrate on the principles of security require you, in your work, your enterprise, and your situation, to address the specifics of the security problems you face, and the protections that you need.  Therefore, in a sense, those frameworks concentrating on principles, rather than individual controls, have the advantage in requiring you to address the specifics that you face.

One of the problems that you will come across frequently, if you explore a range of security frameworks, is that of the definition of secure.  Or, not so much the definition, as the emphasis that a particular security framework may put on one type of security over another.  This may not correspond with your particular needs.  I remember one particular meeting, where two people, sitting next to each other, faced wildly divergent security requirements.  In the case of one, absolute confidentiality was crucially essential.  This particular enterprise dealt with very detailed aspects of businesses, and sometimes businesses that were in competition with each other.  Any breach of confidentiality would have been catastrophic to the trust relationships necessary with their clientele.  On the other hand, this particular agency was a government office, and therefore speed of the processes, and availability of responses, was not necessarily something that anyone expected.  Next to him was someone who dealt with emergency management.  Nobody wanted to actually broadcast details of an emergency, but, given emergency communications, they did have to do so on occasion.  So confidentiality was a rather minor consideration for them.  But, dealing with emergency management, and particularly emergency communication, this particular office was absolutely vital, and it was absolutely crucial that, when someone picked up the phone and called them, somebody on the other end actually answered the phone, and relatively quickly.  Availability was absolutely crucial.  Therefore different frameworks may approach the different types of security, and the different requirements of different types of security, in very different ways.  Ensure, when you are considering a security framework, that it matches your emphasis on your need for your particular type of security.

I have mentioned best practice, and a number of the security frameworks concentrate on this idea of best practice.  Sometimes they present themselves as a best practice in terms of security frameworks.  The thing is, how do you define best?  Are you talking about the most common practice with the widest variety of enterprises?  Are you talking about something that will address the widest range of threats?  As previously noted, none of the security frameworks will address all the threats that you may encounter.  Be very careful when a security framework mentions best practice.  Definitely do not simply accept this as the one that you need, without regard for any other.  Perhaps the best practice is simply to ignore all mentions of best practice.


Security frameworks (SF) series:

Tuesday, June 9, 2026

SF - 1.08.0 - framework types

SF - 1.08.0 - framework types

Security framework types

One of the problems with writing, and particularly structuring, this particular presentation is in trying to determine the different types of security frameworks that exist.  The thing is, there are almost as many types of different frameworks as there are different frameworks.  Those who created different frameworks saw the weaknesses in other frameworks and so created a different type or a different structure of framework to address the failings that they saw with other frameworks.  Therefore each group that tried to create a framework was creating something new and therefore creating, in a way, a different type of framework.

A number of security frameworks could come under the general category of governance.  Governance is, of course, just another way of saying management, and so these tend to address the management of security, or of the organization overall, in a variety of ways.

Most of the governance frameworks tend to be of the breakdown type.  Breakdown doesn't necessarily refer to failure, but rather to the fact that looking at security for an entire enterprise is an enormous task, and can be quite daunting When approaching it for the first time.  So, therefore, we take what some refer to as the salami slicer approach, and try to carve the Enterprise up into smaller pieces which can be assessed more easily.  So, an entire enterprise will be broken down into divisions, and possibly departments, and possibly individual offices or agencies.  When you look at these smaller chunks of the enterprise, they may themselves be subdivided into things like processes.  Once you get down to a small enough size, you can then start to address the issues of security for these smaller units, on a manageable size, rather than looking at the enterprise as a whole.  Having come to certain conclusions in regard to the security requirements and protection requirements and tool requirements for these smaller units, you can then start repackaging the organization back into an integrated whole, and looking for areas where, for example, certain security tools or processes may address the needs of a wider variety of the different units within the enterprise.  This, of course, gives you a sense of the priorities to approach security tools and processes for the enterprise as a whole.

Some of the security frameworks, as mentioned, are of the checklist type.  Most of the checklists are lists of controls and therefore the checklists tend to be of the nature of questions like have you a control for this particular type of situation or vulnerability.  Checklists are easy to use and really only have limitations in terms of are they complete enough for your entire enterprise.

Some security frameworks are directed specifically at the field of risk management, risk assessment,  and risk mitigation.  There are certain security frameworks, like OCTAVE, which are specifically directed at the field of risk management.  However, various business and financial frameworks, which we tend to use widely in the field of information security, are also appropriate for this field of risk management.

Risk management is, I suppose, one example of the class of security frameworks that are oriented towards a specific process.  The frameworks that are specifically directed at the fields of audit and assurance are similarly examples of process-oriented types of security frameworks.



Security frameworks (SF) series:

Monday, June 8, 2026

SF - 1.06.0 - Financial Frameworks

SF - 1.06.0 - Financial Frameworks

The financial industry and community has a more mature risk analysis then do we in the rather new information security community, so some of the financial industries frameworks are often used as security frameworks in dealing with risk analysis.  These include the Sarbanes-Oxley law in the United States, the COSO standard (again from the United States), and the series of Basel international agreements.

(You have to think that the framers of the Sarbanes Oxley law were having a bit of fun.  The two salient sections of the act are section 404 and section 302.  These are, of course, the return codes for "file not found" and "file found" results in HTTP.)

The reliability of reported finances are the primary purposes of these financial frameworks, but this relates pretty directly to information system since information systems are generally the source of the financial reports.

These frameworks also deal with internal controls, and internal controls are a major component of information system controls. 

These controls also consider the problem of insider attack and fraud.  This is an ongoing and fairly intractable problem and these controls are one of the major sources of protection against them.

We will consider COSO in more detail at a later point in this material.



Security frameworks (SF) series:

Saturday, June 6, 2026

SF - 1.03.0 - metrics

SF - 1.03.0 - metrics

Metrics

I need to talk, at least a little bit, about metrics.  Firstly because an awful lot of security frameworks will either demand or provide you with metrics.  Secondly because of the close tie between security and management.  And particularly the statement that what you can't measure you can't manage.  I'm not really sure that I entirely agree with that statement, but it has a lot of merit to it.  An awful lot of people will want metrics to indicate that the security efforts that you make with regard to a certain security framework will in fact improve the security posture in some measurable way.

Of course, as soon as we talk about metrics we start to talk about KPI, or key performance indicators.  This is just really metrics by another name, but management types tend to really appreciate key performance indicators.

In regard to the key part of key performance indicators, I should recommend a book by the name of "PRAGMATIC Security Metrics," by Brotby & Hinson.  Pragmatic is not just a description in the title of this work, but an acronym, pointing out that the security metrics that you choose should be predictive, relevant, actionable, genuine, meaningful, accurate, timely, independent, and cheap.  I highly recommend this work as it points out that not everything that you can measure really gives you any information about how you should manage.  The book itself will provide more details on all of the terms that I have just listed, and I highly recommend it for anyone in really any field of management, but particularly security.

I really enjoy the game of curling.  I appreciate the complexity and strategy of the game.  I tend to tell people that it's like playing chess, if the chess pieces are forty pounds each, and you put them on the board by throwing them down a sheet of ice to a position over a hundred and forty feet away.  No, I am not changing the subject.  If you watch curling on television, the commentator will give you statistics for the players.  But what does it mean if someone has a hit rate of 67%?  What does it mean if a player has a draw rate of 73%?  Operationally, you should either place the stone where it's supposed to be, or not.  That's either a one or a zero.  But, I suppose tactically, have you hit the other stone at precisely the right spot to push it out of the way, or did you get it 67% close to the precise spot?  When you draw down the ice, have you placed the rock perfectly, or is it 73% likely, strategically, that your opponent will not be able to draw around your stone and mess up a subsequent activity?

In terms of management and communication of extremely complex technical information, in an extremely complex and difficult situation, I always recommend that the master class in regard to communication of this sort was the Dr Bonnie show during the pandemic.  The information was delivered, more or less on a daily basis during the high point of the pandemic, not just in terms of the numbers, but in terms of what they meant.  One example was the effectiveness of the vaccines, as they started to come along.  The Pfizer and Moderna vaccines were recommended, because they both had an effectiveness rate of 90%.  AstraZeneca was to be used only as a kind of a last resort, since it only had an effectiveness of 60%.  Presumably this meant that 60% of those who got the AstraZeneca vaccine did not contract the disease during the testing period.  However, AstraZeneca could, quite reasonably, have claimed an effectiveness of 89%, since 89% of those who got the vaccine, whether or not they got covid or not, did not become very ill and did not require hospitalization.  In fact, AstraZeneca could, also reasonably, have claimed an effectiveness of 100%, because no one who got the AstraZeneca vaccine, during the testing regime, actually died of covid, and therefore 100% of those who got the vaccine survived.

Hopefully this goes some way to pointing out that metrics alone, in isolation, are not necessarily the final word on the effectiveness of security.  Security metrics are indicators, and generally very valuable indicators of what is going on.  But you have to understand the implications of the particular metric.  Not everything that can be counted counts.




Security frameworks (SF) series:

Security Frameworks SF - 0.00.0 - intro and ToC

Security frameworks
SF - 0.00.0 - intro and ToC

(You can thank the Technology Forum of the Chartered Professional Accountants of British Columbia for this one.  They asked me to do a presentation, and chose the Security Frameworks presentation [that I hadn't done in a while], which reminded me that I had never dictated the text and resources of this presentation out in full.  So, here it is.)

Security frameworks is a rather vague description, and advisedly so.  That is because there are so many different options in terms of security frameworks: so many different types of security frameworks.  All of them have advice or guidance that can be used to improve your security situation or processes.  None of them, unfortunately, are a one-size-fits-all perfect standard for the creation of a security program.

An awful lot of security frameworks are guidelines, or guidance, towards improving your security posture.  Some stick to the basic principles of security, reminding you of areas which you need to examine.  A number of the frameworks will be standards, of one type or another.  Some of them are fairly generic standards, and so it's hard to distinguish them between from guidelines and principles.  However, others are standards for particular operations or systems, such as the data security standards specifically for the payment card industry.

Some of the frameworks are actual frameworks, and are either structures, or breakdown structures, for examining your existing Enterprise and the security operations and processes within it.

There are a number of security frameworks which basically consists of checklists.  I tend to refer to the checklist style of frameworks as the "135 checklists," since, for whatever reason, most of them have approximately 135 items in the checklist.  There can be a bit of leeway with a few items either more or less, but it has been astounding, over the years, how many of these checklists clock in very close to the 135 item number.  A number of the checklists frameworks either originated as, or have been folded into software of some type, so that the software will walk you through the items on the checklist, and allow you to determine which of these items you have, and which you should examine for inclusion in your own security systems.

A number of the security frameworks will style themselves as either a collection of "best practice" items, or the "gold standard" in security frameworks.  Best practice tends to be the gold standard in terms of a buzz phrase for getting someone to buy into your framework, while gold standard tends to be the best practice in terms of convincing people that your framework is the top of the line.

Some of the security frameworks are targeted at a specific process, even though they may provide guidance for security as a whole.  Sometimes these particular security standards are audit guidelines or outlines.  Sometimes some security frameworks result from legislation or regulation mandated by the government.  Some are reporting standards for a particular industry or a particular process.  Finally there are certain security frameworks that relate to product evaluation.

As noted, all of these frameworks can provide you with guidance in a number of areas.  Unfortunately, none of them are able to provide you with a perfect security situation all on their own.  It is important to know the range and variety of security frameworks so that you can choose a security framework which will complement your existing security situation, and provide you with the greatest opportunity for improvement of your security situation.

In a number of these reference articles I will be including links to certain portions of the full CISSP workshop, which also functions as an introduction to the field of information technology in general.  This link is to the video on security frameworks.


Security frameworks (SF) series:
Introduction and ToC: https://fibrecookery.blogspot.com/2026/06/security-frameworks-sf-0000-intro-and.html (this one)


Security frameworks (SF) series:
Introduction and ToC: https://fibrecookery.blogspot.com/2026/06/security-frameworks-sf-0000-intro-and.html

Wednesday, June 3, 2026

Non-promotional announcement

Rob Slade is not necessarily proud, or ashamed, to announce that he is still retired.

He has not received a promotion.

He has not been a particularly long time in any position.

He has not been awarded any special citation or honour.

He is still enjoying sporadically researching stuff he finds interesting, and hopefully the postings he makes about it are either interesting or helpful to some of you.

You don't have to be jealous that you are not doing what he is doing.  He hopes that you enjoy doing what you are doing, and predicts that, if you keep enjoying your work and doing it, someday you can post a similar posting.



(Which is mostly about "highlights" and "best life" postings on social media.)