Seven Habits of Highly Effective Security Plans [Part 6]
Habit 4 is the first habit to deal with “others”. The first 3 habits are internal – 4 is external.
Think “Win-win”. This is almost impossible for a security professional. Almost.
The issue is that every change to a system (from a lonely PC to a worldwide network) has some risk to the system itself and mostly in terms of availability. In some cases the risk is 100% - for example when a system needs to be rebooted after a patch is applied or even when a service needs to be restarted. It may be a quick reboot and it may be done during a patch window but either way someone needs to sit, sweating and biting their nails, while the box goes through the motions of starting up. In some cases the order that Servers are restarted is important.
I have been attending many job interviews recently and they one question that comes up very often, (and for good reason) is: how do I (Allen specifically) manage teams where there is no will to perform security tasks. It is not easy; security generally does not get given the correct amount of authority to demand that the security tasks get carried out. Nor does the security team generally perform the tasks that are required to keep the organisation secure. Compliance does help (“The auditors are not going to be happy. “) but this sounds like a winey way to get force administrators to perform the security tasks and since Audits are usually annual the Servers tend to be fully compliant once a year at audit time.
Generally, you need buy-in. The easiest way to do this is to live the values yourself. Is it really necessary to patch? Really? All the servers? What if we leave out a couple, maybe the production machines which are all running an older version of Windows? If you don’t have good answers to all of these questions. And by that I mean *good* answers then how do you expect to be taken seriously? The thing I really like about the habits is that they all make sense but more importantly they make sense together. So understanding why you do something is a totally different habit. (Habit one.) Mastering that habit makes you surer of yourself when faced with these questions. It makes it easier to bring the people that count (in this case, the Administrators) around to be on your side.
Once you have buy-in from the Administrators (and their managers) you should approach them to come up with a viable (and practical) plan for performing their tasks. The amazing thing is how much better this works when it has been created by both the security team and the services team (or whoever is going to perform the security task.) When the team knows upfront what is expected and when and can put the methods in place without surprises and has the backing of the security then the processes just flow.
Another place where this habit is important is combatting the idea of the “Dr No. Security Guy”. The idea of this is that Security should not ever be the guy to say “no” to a project or idea without fully thinking it through and trying to arrive at a win-win outcome. It should be a project that is useful to the business, not too expensive to implement and as secure as necessary. A good way of approaching a project that you believe would be too insecure is to start with “I agree that this may be a good idea for the business but I believe that the controls we would need to implement to secure this solution would make it too expensive for any benefits.” You then show what these controls should be and leave it up to the project sponsor to make a decision. Sometimes a project decision made with no thought like “we want it to be a PaaS solution” can be reversed when the security controls are included in the final design without scapping the entire project. Example:
“We want the new solution to be PAAS”
“Why?”
“Because that is our project parameter”
“Um…ok…there are a few things we will need to implement though.”
“Like?”
“Well, for network security we will need to put in a Firewall and IPS and something to monitor them and collect the logs. We will need to do application security since this faces the entire world. We will need to set up someone to monitor all of the equipment. We will need to arrange with the service provider some time to do patching and general maintenance. We will need to do a physical security audit. We will need to have a monthly meeting with the service provider to discuss security controls. The Audit team will need to add this to their annual audit. Plus we will need to investigate the increase in bandwidth costs for us to be able to access the solution. After all that we may need to look at DR and BCP depending on the criticality of this solution.”
-Pause-
-Pause-
“What is the alternative?”
“We host it inside our network where all the infrastructure is already in place and monitored and you have to pay very little for additional security infrastructure. If it helps, we can host it on a virtual machine and you can call it ‘private cloud’”
Win-win.
Habit 4 is the first habit to deal with “others”. The first 3 habits are internal – 4 is external.
Think “Win-win”. This is almost impossible for a security professional. Almost.
The issue is that every change to a system (from a lonely PC to a worldwide network) has some risk to the system itself and mostly in terms of availability. In some cases the risk is 100% - for example when a system needs to be rebooted after a patch is applied or even when a service needs to be restarted. It may be a quick reboot and it may be done during a patch window but either way someone needs to sit, sweating and biting their nails, while the box goes through the motions of starting up. In some cases the order that Servers are restarted is important.
I have been attending many job interviews recently and they one question that comes up very often, (and for good reason) is: how do I (Allen specifically) manage teams where there is no will to perform security tasks. It is not easy; security generally does not get given the correct amount of authority to demand that the security tasks get carried out. Nor does the security team generally perform the tasks that are required to keep the organisation secure. Compliance does help (“The auditors are not going to be happy. “) but this sounds like a winey way to get force administrators to perform the security tasks and since Audits are usually annual the Servers tend to be fully compliant once a year at audit time.
Generally, you need buy-in. The easiest way to do this is to live the values yourself. Is it really necessary to patch? Really? All the servers? What if we leave out a couple, maybe the production machines which are all running an older version of Windows? If you don’t have good answers to all of these questions. And by that I mean *good* answers then how do you expect to be taken seriously? The thing I really like about the habits is that they all make sense but more importantly they make sense together. So understanding why you do something is a totally different habit. (Habit one.) Mastering that habit makes you surer of yourself when faced with these questions. It makes it easier to bring the people that count (in this case, the Administrators) around to be on your side.
Once you have buy-in from the Administrators (and their managers) you should approach them to come up with a viable (and practical) plan for performing their tasks. The amazing thing is how much better this works when it has been created by both the security team and the services team (or whoever is going to perform the security task.) When the team knows upfront what is expected and when and can put the methods in place without surprises and has the backing of the security then the processes just flow.
Another place where this habit is important is combatting the idea of the “Dr No. Security Guy”. The idea of this is that Security should not ever be the guy to say “no” to a project or idea without fully thinking it through and trying to arrive at a win-win outcome. It should be a project that is useful to the business, not too expensive to implement and as secure as necessary. A good way of approaching a project that you believe would be too insecure is to start with “I agree that this may be a good idea for the business but I believe that the controls we would need to implement to secure this solution would make it too expensive for any benefits.” You then show what these controls should be and leave it up to the project sponsor to make a decision. Sometimes a project decision made with no thought like “we want it to be a PaaS solution” can be reversed when the security controls are included in the final design without scapping the entire project. Example:
“We want the new solution to be PAAS”
“Why?”
“Because that is our project parameter”
“Um…ok…there are a few things we will need to implement though.”
“Like?”
“Well, for network security we will need to put in a Firewall and IPS and something to monitor them and collect the logs. We will need to do application security since this faces the entire world. We will need to set up someone to monitor all of the equipment. We will need to arrange with the service provider some time to do patching and general maintenance. We will need to do a physical security audit. We will need to have a monthly meeting with the service provider to discuss security controls. The Audit team will need to add this to their annual audit. Plus we will need to investigate the increase in bandwidth costs for us to be able to access the solution. After all that we may need to look at DR and BCP depending on the criticality of this solution.”
-Pause-
-Pause-
“What is the alternative?”
“We host it inside our network where all the infrastructure is already in place and monitored and you have to pay very little for additional security infrastructure. If it helps, we can host it on a virtual machine and you can call it ‘private cloud’”
Win-win.