Friday, June 12, 2026

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

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

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

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:
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:
Subscribe to: Posts (Atom)