Monday, August 10, 2026

MGG - 7.05 - Dead - Church coffee

So, Gloria is dead, and I my life is over (although I'm still breathing), and I'm in a new town, and the second new town within a year, so I'm trying to not exactly rebuild my life, but build a new life.  So, as I often do, I turn to volunteer work.  But I'm brand new in town, and I haven't yet made any contacts, and I don't even know what kind of volunteer work there is available around here.

One of the first churches that I visit (and, yes, church shopping is also one of the ways of trying to build a new life), on my very first visit to this particular church, is noting that one of the church ladies, a pillar of the church, one of the kitchen and coffee ladies, has died.  Her service is to be the following week.

I know about kitchens.  I know about cooking, but I also know about kitchens. I know about church kitchens.  I don't know about this particular church kitchen, but I know about church kitchens.  I also know the necessities for receptions following services.  So, I contact one of the church kitchen ladies, and I know that I expect that, given the status of the woman who has died, that all the church kitchen ladies will want to attend the service.  So I volunteered to be the one staying downstairs, and also prepared to do the last minute necessities just before the service ends, and everyone troops downstairs for the reception.

So, on the appointed day and time I come along and help, as I can, setting up for the reception.  And, as noted, I volunteered to be the one who has to stay behind and keep an eye on things, while all the rest of the church kitchen ladies get to go up and attend the service for their fallen member.

And, just after everyone has left, somebody that I know from the church comes into the downstairs area, and asks if they can have a cup of coffee before they go up to the service.  This particular church has a two hundred cup coffee urn, which has, in fact, been filled and set perking by the coffee ladies, well in advance of the need for it following the service.  I know, from long experience, going back all with way to my university days when I bought the coffee and supplies for Regent College, that this particular type of coffee urn generally takes a little over an hour to perk its way through and produce coffee.  But, as I say, the coffee ladies have already done their work, and the thing has gone through its entire cycle and the red light has gone off, which indicates, on this particular urn, that the coffee is ready.  So, I tell him so, and say that it's okay for him to get a cup of coffee.  He takes a cup, and draws out a nice steaming cup of hot water.  It's completely clear, although it smells very vaguely of coffee, and it is quite obvious that although the urn has been filled with water, and has gone through its perk cycle, no coffee was actually ever put in with it.

So I race up the stairs, and find one of the church coffee ladies, and inform her of this fact, and also the fact that I have no idea where the coffee is kept in their particular kitchen, nor how much coffee they decide to put in their coffee.  She comes down, and we refill the urn with water, and she puts the coffee in this time, and we set it going, and she heads back upstairs to the service.

As I said, the service was for one of the ladies who was a pillar of the church, and everybody wanted to contribute and so the service was a little bit longer than most similar services.  It was in fact a little over an hour before the service was over, and by the time everybody did troop downstairs, we did have the urn of coffee ready to go.


Friday, August 7, 2026

Algorithms vs lookup tables

I have been working on a science fiction novel for some years now.  I haven't gotten particularly far with it, and I rather doubt that it will ever even be finished.  However, it, in a roundabout way, prompted the idea for this essay.  I suppose the only reason that I am mentioning it is because it is an example of a contention that I have that pretty much any kind of thinking can prompt some useful ideas, and that if you are stuck on something, start thinking about something else.  Generally speaking, thinking about something else will prompt some ideas about what you think you are supposed to be thinking about.

(I don't really have an awful lot of sympathy for those who profess to be afflicted by writer's block.  I can't really say that I have ever been afflicted with writers block.  Maybe I just don't have enough experience, but I do have an awful lot of experience in writing, and in doing all kinds of writing.  Like I said, generally speaking, if you get stuck and can't move forward with a particular piece of writing, then start thinking and writing about something else.  Very often writing about something else leads to thinking about, or some ideas about, whatever it is that you think you're supposed to be writing about.)

The idea that came to me was one that I have frequently had when I have been teaching about technology, and frequently at a very high level.  I am old.  Old people are not supposed to be in the forefront of technology.  And, indeed, I cannot claim that I am in the forefront of any particular field of technology.  But I am teaching those who are.  And one of the things that I have realized, over the years, is that being up on the latest technology is not as important as having a foundation on the basics of technology.  Understanding that knowing the latest app, or programming language, or agentic process with artificial intelligence, or the most recent technology architecture technology with regard to quantum computers, isn't as important as understanding the basics of the bulk of the architecture that is in use today.  As Newton said, we see further because we stand on the shoulders of giants.  We have to understand where we are in order to see where we can get to.

But this is a broad and general outlook.  The particular idea that came to me was one that goes back to a course that I took on machine and assembly language processing, and the building of functions with hardware circuitry.  When you were designing at this most fundamental level, programming with direct machine language, rather than using a higher level language to speed up the process, you start to understand that there are two ways of doing anything: using an algorithm, or using a lookup table.

Computers do arithmetic with binary arithmetic.  When we want to get an answer from a computer, however, we ask it to present it to us in decimal, which is what *we* are used to using.  So, if you are not just calling for functions from a programming language, you have to build your own conversions from binary numbers to binary coded decimal.  There are two ways that you can do that.  You can use the algorithms that will convert a binary number into pieces that can then be used to display decimal numbers on the screen.  Or, you can simply create a lookup table, and directly convert the binary number into a series of pieces that can be displayed on the screen.

Whether you choose an algorithm or a lookup table will depend on how much work you were doing, and partly on how much processing time is going to be used by the algorithm versus simply using a lookup table.  Partly this is determined by the size of the numbers that you were working with.  There are going to be some situations where an algorithm is far superior, but there are also going to be situations where a lookup table is much quicker and easier, not only to create, but also to use.

And I as I was thinking about this fact, I realized that the current grand interest in artificial intelligence, the large language model, is created using neural networks, Bayesian analysis, and Markov chains.  But that is what we use to *create* the large language model, itself.  When we *use* the large language model, the large language model is acting as an enormous lookup table.  An enormously complicated lookup table, it is true.  But, in the end, it is merely a lookup table.  This explains a lot of the limitations of large language models.

Looking back through the history of artificial intelligence, lookup tables feature very prominently.  ELIZA, or doctor, one of the earliest successful artificial intelligence programs, used a lookup table, although the lookup table was used to discard parts of language that were not essential, allowing the program to concentrate on the more important and relevant aspects of a conversation and therefore appear to be very wise in its questioning of its clients.  Expert systems are a rather odd kind of lookup table, using a binary tree to ask yes and no questions to get to the basis of an answer for a particular expert field.

Current large language model artificial intelligence systems are incredibly expensive, require enormous data centers to operate, and have a voracious appetite for stupendous quantities of energy.  To put it bluntly, they are incredibly wasteful.  They are massively expensive, contribute to e-waste, and are going a long way to driving global warming.  We need to change things.

We need to look at some efficiencies here.  And, in the same way that dealing with very large numbers when we are trying to code binary numbers into decimal representation, we need to stop thinking about lookup tables, and start thinking about the more efficient, in the long term and on the large scale, algorithms.

We need to stop playing around with systems that use enormous amounts of computer hardware, and massive amounts of energy to drive them, in order to give us some interesting but possibly not important results.  We need to start looking at the algorithms of actual intelligence.  What are we actually doing when we are thinking.  How are *our* thinking processes adaptable to silicon hardware.

And so we come full circle in this essay.  We have developed writer's block for ourselves by focusing too long on lookup tables in creating our artificial intelligence.  It is time for us to look at, and do the harder work in creating, the algorithms necessary to develop true artificial intelligence.

AI topic and series

Saturday, August 1, 2026

MGG - 2.0a - Teaching - sailing, lightning at Gull Lake

(By the time that I remembered to write this up, I couldn't figure out whether it properly belongs with teaching, or with stories about work.  So, in terms of what has already been posted on the blog, it more easily fits here in the numbering scheme, so we'll leave it here, and see if anything happens later.)

As noted with the story about scouting, I had some experiences with outdoor education before I actually got into the formal education system as a teacher.  One of the experiences was that I was asked to be a sailing instructor at Gull Lake Baptist Camp in Alberta for a summer.  I hadn't lived in Alberta for any time prior to this, although I had visited for brief times, so it was interesting to learn the difference between living in a rain forest, and living on the prairies.

While I had done a lot of volunteering as a camp counselor in summer residential kids camps, this was my first experience as sort of full-time summer program staff for such a camp.  We didn't have to bunk in with the kids as full-time staff, so we did have our own accommodation.  I bunked in with another one of the male full-time staff, the two of us in a small, four room, log cabin.  The log cabin was constructed of cottonwood logs, and was definitely showing evidence of the reason that very few people build log cabins out of cottonwood logs.  Living in a rainforest I am familiar with the number of different types of tree species, and particularly those that can be cut up for firewood.  Cottonwood is unique in my experience in that it goes directly from a water logged state, to being rotten punk wood, with no indeterminate state of being useful for, well, pretty much anything.

One of the interesting aspects of living on the prairies was that of thunderstorms.  It's not the thunderstorms don't happen in the rainforest: these days we have constant evidence of the fact that thunderstorms can ignite wildfires in remote locations, which can make it very difficult to deal with those fires.  However, living in a rainforest, even on an island, thunderstorms are relatively few along the coast, and, in other places, generally don't happen where they are visible to you.  So, this was the first time that I had the experience of being able to see lightning storms, and be reasonably certain of being able to see a lightning strike, even if that lightning strike was several miles away across the lake and fields.  Another of the staff who was interested in photography and I went down to the lakeshore one night, when there was a thunderstorm that was striking on the other side of the lake, and we were accompanied by my housemate, who was terrified of the fact that we were down on the beach, obviously the highest point on the beach, and therefore, in his mind, subject to lightning strikes, even though the lightning was striking on the other side of the lake.

But there was another thunderstorm incident that was closer to home, as it were.  We were having a staff meeting, which happened to be held in the log cabin that was my residence, when we heard a thunder that happened at the same time as a brilliant flash of light.  This obviously meant that the lightning strike had been relatively close to us, and presumably somewhere on the camp.  So we all spilled out of the cottage, and had a quick look around all the buildings that were on the property, noting that none of them showed any evidence of lightning strikes.  When we reassembled back at my log cabin, we realized that one of the trees, immediately outside an unused door, showed evidence of missing bark and missing splinters of wood, which seemed to be evidence that it was a lightning strike.  When we examined more closely, we realized that there was heat damage to a clothesline that ran from the tree to a post holding up a small covering over the doorway, and then noticed that from that particular post, the handrail beside the door also showed some damage and missing splinters of wood.  When we got back inside the house, we found that, yes, the lightning strike had entered the house, and blown out a chunk of plaster--immediately behind the chair in which I had been sitting during our meeting.

I should note that the time as sailing instructor was not without incident itself.  The sport of sailing is not unknown on the prairies, but nobody in the camp had any experience with sailing or sailboats.  Therefore, when they were deciding what kind of boats to buy for the sailing program, they had simply asked another organization what boats they had recently purchased.  The boats in question shall not be named because it is probably unfair to tarnish their reputation given the problems with one particular model of their sailing craft.  These particular boats constantly surprised me, all summer long, with different ways that they had to injure or kill you.  The first thing that we learned was that the two-piece molded fiberglass construction was joined together with channel rail, and that the channel rail had extremely sharp edges, with no attempt to cover those edges.  Therefore, when we were lifting the boats on and off the beach, an awful lot of the kids got cut fingers handling the boats.  Eventually we developed a number of safety protocols for the use of these boats.  One of the rules was that no camper was to be allowed to hoist the boats in or out of the water.  Another was that no camper was to be allowed in the boats without an adult who had at least some experience with sailing with them.  We found that the sailboats would not sail without their jib actually in place.  We found that this sailboats would not sail if only the jib was in place, and if the mainsail was not operable as well.  We found that the boats were extremely slippery, and that the seating, on the gunnels, was not stable and that it was quite easy for anyone who was on board and sitting on the gunnel to slip off the gunnel and fall overboard.  We also found that it was quite easy for the boats to turn turtle, as the term has it, turning completely upside down.  Generally speaking it was relatively easy to bring the boat upright again by standing on the bottom of the gunnel, grasping the center board, and using your weight to bring the mast back up.  But on one occasion, when we were doing that, in the middle of the lake, I was not able to move the boat to an upright position, or bring the mast up at all.  I was sailing with the camp director on that particular occasion, and observed that I had never seen this particular inability to right the boat.  He suggested that the mast was stuck in the bottom of the lake.  I observed that the mast was only eighteen feet high, and surely the middle of Gull Lake was not that shallow.  He nodded thoughtfully at my observation, and then repeated, maybe the mast is stuck at the bottom of the lake.  When we got the boat back upright, and observed mud on the top of the mast, we verified that his assumption had been correct.


Monday, July 27, 2026

Sermon 89 - Purple Peacock

First indications that my purple peacock plants might produce this year.


Sermon 89 - Purple Peacock

John 12:24
Very truly I tell you, unless a kernel of wheat falls to the ground and dies, it remains only a single seed.  But if it dies, it produces many seeds.


I have never actually bought seeds for purple peacock beans.  I was given four pods by a fellow gardener one time.  Instead of eating the beans, I opened up the pods, extracted the beans, dried them, and later used them as seed.

Purple peacock beans grow, cook up, and can be eaten like green beans.  They have a slightly tougher outer skin, and a slightly milder flavor.  The outer skin is purple, but, if you cook the beans, some of the purple color disappears, and you tend to end up with either a mottled or striated mix of purple and green, which can be quite colorful depending upon the recipe you cook them in.

A couple of years ago I planted some purple peacock beans in a mixed garden patch.  I planted two of the seeds beside two very large sunflower plants.  I had a large number of poles stuck randomly around the garden.  Purple peacock plants grow quickly and prolifically, generating a large number of tendrils, and twining around and over pretty much everything.  They spend a long time producing vines and leaves, and it's only after a few months of producing vines and greenery that you finally get a few small purplish flowers.

I have, elsewhere, written a sermon or devotional about broad beans as an example of God's Providence.  Purple peacock beans don't produce edible material in quite the same variety as broad beans do, but purple peacock beans definitely surpass broad beans in terms of actually producing food.

I probably planted five purple peacock plants in that mixed garden.  The greenery overtook pretty much the entire garden.  When once the beans started to produce, I probably took, at a conservative estimate, five kilograms of beans off each plant.  I could have taken more, if I had allowed the pods to grow to their full size, and if I had maintained a regular schedule of harvesting later into the season.

Jesus once spoke a parable about the importance of sacrifice, even the sacrifice of your own life.  He noted that a single seed was not very much, but that, when planted in the ground it died, but then produced a harvest, of thirty, or sixty, or even a hundred times the original grain.  The purple peacock beans that I planted outdid that by a considerable margin.  Each seed was approximately two grams in size.  Each plant produced at least five kilograms of food.  That's a 2500 times increase.

We can find other, even more prolific, examples.  An apple seed, less than a gram, can produce a tree which, after a few years, yields dozens of kilograms of apples every year.  And, of course, I have also, elsewhere, noted that God doesn't seem too concerned with efficiency.  God provides for us profligately, showering abundance on us.


Garden series

Sermon 2 - Broad Beans

Sermon 3 - Blackberries

Sermon 33 - Transplanting

Sermon 57 - Leaven

Sermon 59 - Corn

Sermon 83 - The Years the Locusts Have Eaten



Sermons: https://fibrecookery.blogspot.com/2023/09/sermons.html

Saturday, July 25, 2026

Review of "Animal Farm" by Angel Studios

I have seen quite a number of productions by Angel Studios.  And I know the book "Animal Farm."  In fact, I have seen multiple movie or video adaptations of "Animal Farm."  So I was a bit surprised to see that Angel Studios would be doing a version of "Animal Farm." The productions by Angel Studios have happy endings.  "Animal Farm" does not have a happy ending.  George Orwell wasn't very big on happy endings.

But then the movie started, and I thought that this must be some different story, since the first animal we are introduced to is Lucky the pig.  I don't remember the part that Lucky the pig plays in George Orwell's "Animal Farm."  Oh, but wait.  Then we are introduced to Boxer, and Napoleon, and Snowball, and Farmer Jones, so maybe we *are* in Orwell's "Animal Farm."  Except that we also have some giant mega corporation buying a farm, and a drone, called Moses, which don't appear in "Animal Farm."

So it's confusing.

The story development of Orwell's "Animal Farm" proceeds pretty quickly, with Snowball being exiled, and Napoleon starting to take over.  (However, the allusions to the Russian revolution are a bit rushed, and therefore lost.)  Angel Studios is very heavily Christian oriented, so it isn't terribly surprising that the story relies less on political machination, and much more on temptation.

The plot of the original "Animal Farm" gets severely messed with, but the theme of new revolutionaries re-implementing the old dictatorship proceeds pretty much as it always did.  Electricity is good, then bad, then good ... and then maybe bad?  Then we get the ending of the "Animal Farm" book, but this movie doesn't finish.

Then we kind of go all "Animal *House*" for a while, and then we finally have a ... well a kind of an indeterminate ending, but I suppose that it could be *seen* as a happy ending.  At least there are a lot of warm and fuzzy sounding platitudes before we all sit and look at the stars, and consider that all the animals who went to the slaughterhouse could be coming back as stars.  Maybe.  Maybe you only come back as a star if you went to the glue factory instead of the laughterhouse.

The moral of the story is that farm markets are good, and wearing hazmat suits is evil.  (The reason why is too complicated for your little piggy brain.)

Or maybe that you can never go wrong as long as you remember that Snowb... Napo... Luck... Boxer is always right.  Except when he's wrong.

Or maybe that someone pretending to be your Dad is always evil.  But people who claim bast friend status are good.

Or maybe that astrology is based on your dead friends coming back as stars.


(Possibly Angel Studios should stick to making feel good films for adults, and avoid simplifying literature for kids.)

Friday, July 24, 2026

Branded Call Display

As it was turning off, my phone offered me branded call display.

That was all I could read before it shut off.  So, I was wondering why on earth I would want branded call display?  Was this something that would allow Norton to jump in whenever I got a spam telephone call, and announce that if I purchased Norton for my phone it would have diverted the call from Telemarketers-Backwards-R-Us?  Would Ford be allowed present the fact that if I purchased a new vehicle it would make the drive to Esther Singleton's house, at 3:25 Oak View Crescent, a distance of 2.7km, much more comfortable?

So I looked up branded call display, and found that, no, it wasn't my phone that would generate the display, but the idea that, if I was a company, I could purchase the fact that Call Display would no longer display the number that I was calling from (even if it was false), and would instead present the name of a company.  So I guess this is why so many recent spam and scam calls are coming to me from "British Columbia."

Wednesday, July 22, 2026

Review of "Deep Water," 2026, with Aaron Eckhart and Ben Kingsley

"Deep Water" seems to be a very popular movie title, so I have to specify not only the year, but also the stars, since at least *two* movies of that name were released in 2026.

If you know anything about airplanes, aircraft design, water, aircraft flight paths, ocean waves, securing cargo on passenger aircraft, where Guam actually is, or water pressure, you will be annoyed by this film.  (I don't know much about sharks, but I presume that they got most of that wrong, too.)

Given the prevalence of screens and devices, and the fact that the whole thing is set off by a faulty device, it could be seen as an indictment of our modern screen-oriented society.  Or maybe just that smoking can kill you.  (In more ways than one.)

I don't know why Aaron Eckhart and Ben Kingsley signed on to such an egregiously error-laden turkey, but I suppose anyone can make a mistake, and a lot of the goofs wouldn't be as obvious in script form.  (Kingsley gets to die relatively quickly.)

Here's looking at you ...

My computer has a camera.  As a security maven, I don't trust the software switch that turns the camera off (when I don't want it on), and have installed a shutter to physically block the camera.

Yesterday, when I went to start a virtual meeting, the shutter was still closed.  The computer, and the meeting software, warned me that something might be blocking the camera.

So, the computer can figure out that I've probably installed a shutter over the camera.

I'm not sure how I feel about that ...

Friday, July 3, 2026

Jonah 4:9

But God said to Jonah, “Is it right for you to be angry about the plant?”

“It is,” he said. “And I’m so angry I wish I were dead.”

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.)

Wednesday, May 20, 2026

CoSMI - 1.0.1.22 - Authenticity - True Self - job interview tricks

CoSMI - 1.0.1.22 - Authenticity - True Self - job interview tricks


In a long lifetime, with many career changes, I have spent far too much time in job interviews.  I have also received a great deal of advice on job interviews, and how to affect them in your favour.  I have come to believe that an awful lot of this advice is absolute nonsense.

A great deal of advice that people give you about job interviews and about preparing resumes turns on the proposition that you should present yourself differently than you actually are.  People will tell you that companies are on the lookout for go-getters, and so, regardless of what you are actually like, you should present yourself as a go-getter!  Of course, if you present yourself in this way and the company hires you, thinking that you are a go-getter, then when you get the job, the company will expect you to go and get, regardless of what your skills actually are.

It's basically the same as if the company wants a morning person because they need somebody for the early shift.  You get the job by presenting yourself as a morning person, even though you are really a night owl.  On the job, you are continually coming in late or being absolutely useless for the first few hours of your shift because you are absolutely exhausted from being up late the night before.  It's not your fault that you are a night owl.  That is the way that you were made.  But it *is* your fault for presenting yourself incorrectly.  You're not happy, and the company's not happy.

One aspect of this problem is that it is not just the candidates for the job who are being told tricks for job interviews.  An awful lot of the job interviewers are also being told that they have to have tricks for the job interview.  They have to have group interviews, or confrontative interviews, or trick questions to fire at candidates at random times during the interview.  Tricks are always shortcuts, and a form of cheating, and cheaters never prosper.  Using interview tricks doesn't work any better for the companies than it does for the candidates. It just means that you end up with the wrong people in the wrong jobs, and then nobody is happy.

Really, this is just another way of saying the same thing that I have been saying all along.  Be yourself.  Be true to yourself.  Don't change just because somebody says you need to be something else.  If you need to be something else in order to do what you think you want to do, then you shouldn't be doing that.



CoSMI series:
Next: TBA