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:
Next: TBA
Posted by at No comments:

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:
Posted by at No comments:

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:
Posted by at No comments:

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:
Posted by at No comments:

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
Posted by at No comments:

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.)
Posted by at No comments:

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
Posted by at No comments:
Subscribe to: Posts (Atom)