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

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