A more positive and comprehensive SABSA Strength-in-depth Strategy
[Extending SABSA's Strength-in-Depth Strategic Controls]
What is very interesting is that Business people understand risks. That is what they do. They understand governance and they also understand (to complete the GRC triad) compliance. They may just not understand IT specific Risks, controls, etc. Usually IT is structured that the Business talks to the CIO or some form of "Business Specialists" who represent IT to the Business. But, the CIO usually doesn't understand risks and the Specialists almost certainly don't. IT is not keen to wheel out the Security guys to talk to Business but SABSA is a useful tool to help all three parties - IT, Business and Security to talk positively and come up with real solutions.
One of the really clever features of SABSA is that when it comes to "Attributes" which are basically "things the company would want to have" - they are all positive. "We want to put these controls in place so we don't fail our Audit" is not as good as "If we implement these controls, we will be totally compliant". "If we don't fix the authentication issues, someone may hack us and change stuff" is not as good as "If we fix the authentication issues, we will have a higher level of comfort around the integrity of our financials." A Business person hearing that will hear "blahblahblah..comfort..integrity..financials" and will give you at least some time to explain the "blahblahblah". Brilliant.
All fired up after the course, I was thinking about how to write Standards so that they would have a similar level of positivity in their descriptions. The first Standard I turned to was the Firewall Standard. I then looked at the SABSA Strategy-in-depth sheet and it was obviously a "Prevent" control. (Or Preventative, even.) But that is the default state of a Firewall and has the same effect as unplugging the cable from the Internet router. You are essentially preventing everything... this is very safe... but not very useful, obviously. So, we open rules for traffic that is allowed. This is necessary and fits in with the whole SABSA features of "business driven" and "risk and opportunity based". So, for this to work - there should be a positive to each of the negatives for the Strength-in-depth controls.
"Prevent" was easy - the opposite is "Allow". So, working from this - a Firewall Policy is a combination of negative and positive controls that allow good traffic flow and prevent bad traffic flow. Restating that - "We have a Firewall with a policy/rule-base/control-list that blocks bad traffic so as to allow good traffic to enable good business transactions".
Spam-control - "We prevent spam at the border and allow good mail to flow inside our network to make management of mail more efficient, cost effective and keeping staff motivated."
I chose to group these actions as "Enforcement".
That was quite easy... what about "deter"? Well, deter is informing "users" of what not to do and what the consequences may be. The opposite is informing user what they can do and informing them of the benefits of connecting. My choice of word for this is "invite" and the group is "negotiate". This can cover more than just MOTDs and logon warnings. Once you add the positive aspect to it, it can cover Acceptable Use Policies and Terms and Conditions.
The interesting thing is that once you define "Negotiate" and "Enforce" and add in the positive aspects - they also flow easier - once you negotiate that someone may use a certain system - you remove the enforcement that denies them access and allow them to access the system within the limits of what was negotiated.
So, those are the first two controls in the strategy - the easier two. The others are "contain", "detect and notify", "evidence and track","recover and restore" and "assure". My feeling is that "assure" is the odd one out. It is almost a meta function of this process. In programming terms we would have an API that feeds what we are doing into the next level for assurance. "The Firewall is blocking all bad traffic and allowing all good traffic" is assurance. So for each control we need to consider "assurance" but I don't believe it deserves a category all of its own.
Moving along, I have had some difficulty in working out the positive aspects of the other controls. "Contain" is like an adhoc post-breach denial of a certain type of traffic or user or system. This could fall into "Enforcement" as "Post Breach Enforcement" which would have the positive being "allow known good traffic or system or user to operate without being influenced by known bad traffic which is contained (denied access to the known good systems)."
I have grouped "Detect and notify" into "Activity Monitoring". If it is a good transaction then it should be detected and the service can be performed on it. If it is a bad transaction then it should be detected as such and the correct person should be notified in a predefined timespan.
"Evidence and Track" can be done for all traffic. This is "Traffic monitoring". Bad traffic should be recorded and analysed. Good traffic should be baselined and services improved accordingly. I have called this "Traffic Monitoring" but I think it can be used for all types of actions. However, I believe it to be more general than Activity Monitoring which looks at a specific event in depth, whereas this applied to a more broad stream of activities. "Activity Monitoring" would notify of a user locked out of their account. "Traffic monitoring" would notify of a number of strange attempts to guess passwords across the organisation.
"Recover and Restore" is very important but I haven't applied a positive aspect or generalisation to it just yet. I think it deserves more thought.
So, in summary - here is my list with the original SABSA strategic controls - my generalised groups and the additional positive strategic controls.
This is still a work in progress so any comments or creative criticism would be appreciated.
I haven't used this model in any practical applications but I am keen to as soon as possible.
[Extending SABSA's Strength-in-Depth Strategic Controls]
What is very interesting is that Business people understand risks. That is what they do. They understand governance and they also understand (to complete the GRC triad) compliance. They may just not understand IT specific Risks, controls, etc. Usually IT is structured that the Business talks to the CIO or some form of "Business Specialists" who represent IT to the Business. But, the CIO usually doesn't understand risks and the Specialists almost certainly don't. IT is not keen to wheel out the Security guys to talk to Business but SABSA is a useful tool to help all three parties - IT, Business and Security to talk positively and come up with real solutions.
One of the really clever features of SABSA is that when it comes to "Attributes" which are basically "things the company would want to have" - they are all positive. "We want to put these controls in place so we don't fail our Audit" is not as good as "If we implement these controls, we will be totally compliant". "If we don't fix the authentication issues, someone may hack us and change stuff" is not as good as "If we fix the authentication issues, we will have a higher level of comfort around the integrity of our financials." A Business person hearing that will hear "blahblahblah..comfort..integrity..financials" and will give you at least some time to explain the "blahblahblah". Brilliant.
All fired up after the course, I was thinking about how to write Standards so that they would have a similar level of positivity in their descriptions. The first Standard I turned to was the Firewall Standard. I then looked at the SABSA Strategy-in-depth sheet and it was obviously a "Prevent" control. (Or Preventative, even.) But that is the default state of a Firewall and has the same effect as unplugging the cable from the Internet router. You are essentially preventing everything... this is very safe... but not very useful, obviously. So, we open rules for traffic that is allowed. This is necessary and fits in with the whole SABSA features of "business driven" and "risk and opportunity based". So, for this to work - there should be a positive to each of the negatives for the Strength-in-depth controls.
"Prevent" was easy - the opposite is "Allow". So, working from this - a Firewall Policy is a combination of negative and positive controls that allow good traffic flow and prevent bad traffic flow. Restating that - "We have a Firewall with a policy/rule-base/control-list that blocks bad traffic so as to allow good traffic to enable good business transactions".
Spam-control - "We prevent spam at the border and allow good mail to flow inside our network to make management of mail more efficient, cost effective and keeping staff motivated."
I chose to group these actions as "Enforcement".
That was quite easy... what about "deter"? Well, deter is informing "users" of what not to do and what the consequences may be. The opposite is informing user what they can do and informing them of the benefits of connecting. My choice of word for this is "invite" and the group is "negotiate". This can cover more than just MOTDs and logon warnings. Once you add the positive aspect to it, it can cover Acceptable Use Policies and Terms and Conditions.
The interesting thing is that once you define "Negotiate" and "Enforce" and add in the positive aspects - they also flow easier - once you negotiate that someone may use a certain system - you remove the enforcement that denies them access and allow them to access the system within the limits of what was negotiated.
So, those are the first two controls in the strategy - the easier two. The others are "contain", "detect and notify", "evidence and track","recover and restore" and "assure". My feeling is that "assure" is the odd one out. It is almost a meta function of this process. In programming terms we would have an API that feeds what we are doing into the next level for assurance. "The Firewall is blocking all bad traffic and allowing all good traffic" is assurance. So for each control we need to consider "assurance" but I don't believe it deserves a category all of its own.
Moving along, I have had some difficulty in working out the positive aspects of the other controls. "Contain" is like an adhoc post-breach denial of a certain type of traffic or user or system. This could fall into "Enforcement" as "Post Breach Enforcement" which would have the positive being "allow known good traffic or system or user to operate without being influenced by known bad traffic which is contained (denied access to the known good systems)."
I have grouped "Detect and notify" into "Activity Monitoring". If it is a good transaction then it should be detected and the service can be performed on it. If it is a bad transaction then it should be detected as such and the correct person should be notified in a predefined timespan.
"Evidence and Track" can be done for all traffic. This is "Traffic monitoring". Bad traffic should be recorded and analysed. Good traffic should be baselined and services improved accordingly. I have called this "Traffic Monitoring" but I think it can be used for all types of actions. However, I believe it to be more general than Activity Monitoring which looks at a specific event in depth, whereas this applied to a more broad stream of activities. "Activity Monitoring" would notify of a user locked out of their account. "Traffic monitoring" would notify of a number of strange attempts to guess passwords across the organisation.
"Recover and Restore" is very important but I haven't applied a positive aspect or generalisation to it just yet. I think it deserves more thought.
So, in summary - here is my list with the original SABSA strategic controls - my generalised groups and the additional positive strategic controls.
This is still a work in progress so any comments or creative criticism would be appreciated.
I haven't used this model in any practical applications but I am keen to as soon as possible.