Cyber Security Awareness Month - Day 30 - DSD 35 mitigating controls

Cyber Security Awareness Month - Day 30 - DSD 35 mitigating controls
Nearing the end of the month it would be remiss not to mention the DSD 35 mitigating strategies. Whilst not strictly a standard it provides guidance and The Defence Signals Directorate or DSD is an Australian government body that deals with many things called Cyber. Amongst other things they are responsible for providing guidance to Australian Government agencies and have produced the Information Security Manual (ISM) for years. In the past few years they have expanded on this and produced the DSD 35 mitigating strategies. The DSD 35 mitigating strategies are based on examination of intrusions in government systems and have been developed to address the main issues that would have prevented the breach in the first place. In fact DSD states that by implementing just the top 4 strategies at least 85% of the intrusions would have been prevented. The top four are: Application whitelisting Patch Applications Patch operating system vulnerabilities Minimise the number of users with domain or local administrative privileges. Implementing the top 4 (Some general hints anyway) Application whitelisting Application whitelisting is one of the more effective methods of preventing malware from executing and therefore the attack from being effective. The main argument you will hear against this is that application whitelisting is difficult to achieve, which in a sense is correct. It will take effort to get the environment to the point where everything functions as it should. However in the whitespace following the top 4 is a good piece of advice form DSD "Once organisations have implemented the top four mitigation strategies, firstly on computers used by employees most likely to be targeted by intrusions and then for all users, additional mitigation strategies can then be selected to address system security gaps to reach an acceptable level of residual risk." In other words address the high risk users and issues first and then propagate the control to the remainder of the organisation. There are a number of tools available that will implement application whitelisting and the initial prolong of systems in order to get the whitelisting right. A number of end point products are also capable of enforcing it and of course app locker in windows can also do the job. When implementing it, make sure you do this in test environments first to sort out the issues. Patch Applications Patching applications is something that we all should be doing, but can be difficult to achieve. One issue that I come across is "the vendor won't let us". Providers of certain applications, usually expensive, will not allow the environment to be changed. If you patch the operating system or supporting products they'll not provide support. In one extreme case I'm aware of the vendor of the product insisted the operating system was reverted back to XP SP2 before they would provide support. Those situations are difficult to resolve and unfortunately I can't help you out there. However going forward it may be an idea to make sure that support contracts allow for the operating system and other supporting products to be patched without penalty. As a minimum identify what really can't change and what can. So outside of those applications that are just too hard, implement a process that patches applications that can be patched, maybe remove those that are really not needed. For those applications that are to hard, you will have to find some other controls that help you reduce the risk to them, possibly strategy one? Patch operating system vulnerabilities Many organisations have this sorted reasonably well. A number of operating system provide a relatively robust process to update operating system components. One of the clients I work with does the following which works for them. When there is an advanced notification the bulletin is analysed. A determination is made whether the patch needs to be applied and how quickly. Once they are released they are implemented in the DEV environment straight away and systems are tested, assuming they do not break anything the patches are implemented in UAT and other non production environments. Systems are tested again (A standard testing process mostly automated). Production implementations are scheduled for a Sunday/Monday implementation. Assuming there are no issues stopping the implementation everything is patched by Monday morning. It takes effort, but with some automation the impact can be reduced. There are also a number of products on the market that will assist in the patching processes, simplifying life. Minimise the number of users with domain or local administrative privileges. Removing admin rights will also take a little bit of effort. Identify those that have administrative rights, domain or local. Identify what functions or roles they actually perform that require those full rights. Take local admin rights as an example. There are some applications that really do require the user to have local administrative rights. However there are also plenty that "need" them for the sake of convenience, rather than figuring out what access is really needed admin rights are given. Some applications you come across need admin right the first time they are run, after that no more. Your objective should be to remove all local admin rights from users and reduce domain administrative rights to as few as possible accounts in the environment. You will need to test before implementing in production. If it all seems overwhelming break it down into smaller jobs. Do those devices that are critical to the organisation first and then expand the efforts. But once done you will have reduced risk to the organisation and you can start looking at implementing the remaining 31 controls. As I said at the start not necessarily a standard, but how often can you say that you know of a way to reduce risk of targeted attacks by 85% or more? I'm interested in finding out how you may have implemented one or more of the top 4 controls, please share by commenting, or let us know via the contact form and I'll add contributions later in the week. Mark H - Shearwater http://www.dsd.gov.au/infosec/top35mitigationstrategies.htm	Mark 391 Posts ISC Handler
Reply Subscribe	Oct 30th 2012 6 years ago
I was suprised to see that there was no explicit mention of disallowing default passwords. Perhaps it is covered by #27 "Enforce a strong passphrase policy", but not clearly.	T 31 Posts
Reply Quote	Oct 31st 2012 6 years ago
Minimizing local and domain privileges is a big struggle, but has a big payoff. Our environment used to be really bad. All users were local admin and just about every member of IT was domain admin. Reading email as domain admin. shudder First, we started with IT. We surveyed what each person in IT was doing and created access groups that would allow them to perform their job without Domain Admin. Help Desk was given rights to AD and other areas they needed without giving them full access. Same with devs and sys admins. Now they could use their regular login (sans Domain Admin) to perform 95% of their daily duties. For those in IT that required Domain Admin, we created a special account for them that allowed them to elevate when necessary. A few tweaks to permissions were necessary to get everything right, but it wasn't that hard. Most of the effort was around convincing everyone that they could still do their job without Domain Admin. Next, we removed local admin from users. GPOs were used to enforce a list of user and groups in local admin, local power users, and local users. Most of our users went in a domain level "Power Users" group that was a member of the local Power Users group. Of course, there were applications that complained. We used Process Monitor to figure out where we were getting Access Denied errors. Then we would use a GPO to grant the needed folder permissions. It took a little work, but overall it went well. Of course, we also have a group we can put users in if they need local admin. But the IT manager must approve all additions to this group.	T 3 Posts
Reply Quote	Oct 31st 2012 6 years ago

Nearing the end of the month it would be remiss not to mention the DSD 35 mitigating strategies. Whilst not strictly a standard it provides guidance and The Defence Signals Directorate or DSD is an Australian government body that deals with many things called Cyber. Amongst other things they are responsible for providing guidance to Australian Government agencies and have produced the Information Security Manual (ISM) for years.

In the past few years they have expanded on this and produced the DSD 35 mitigating strategies. The DSD 35 mitigating strategies are based on examination of intrusions in government systems and have been developed to address the main issues that would have prevented the breach in the first place. In fact DSD states that by implementing just the top 4 strategies at least 85% of the intrusions would have been prevented.
The top four are:

Application whitelisting
Patch Applications
Patch operating system vulnerabilities
Minimise the number of users with domain or local administrative privileges.

Implementing the top 4 (Some general hints anyway)
Application whitelisting
Application whitelisting is one of the more effective methods of preventing malware from executing and therefore the attack from being effective. The main argument you will hear against this is that application whitelisting is difficult to achieve, which in a sense is correct. It will take effort to get the environment to the point where everything functions as it should. However in the whitespace following the top 4 is a good piece of advice form DSD "Once organisations have implemented the top four mitigation strategies, firstly on computers used by employees most likely to be targeted by intrusions and then for all users, additional mitigation strategies can then be selected to address system security gaps to reach an acceptable level of residual risk." In other words address the high risk users and issues first and then propagate the control to the remainder of the organisation.

There are a number of tools available that will implement application whitelisting and the initial prolong of systems in order to get the whitelisting right. A number of end point products are also capable of enforcing it and of course app locker in windows can also do the job. When implementing it, make sure you do this in test environments first to sort out the issues.

Patch Applications
Patching applications is something that we all should be doing, but can be difficult to achieve. One issue that I come across is "the vendor won't let us". Providers of certain applications, usually expensive, will not allow the environment to be changed. If you patch the operating system or supporting products they'll not provide support. In one extreme case I'm aware of the vendor of the product insisted the operating system was reverted back to XP SP2 before they would provide support. Those situations are difficult to resolve and unfortunately I can't help you out there. However going forward it may be an idea to make sure that support contracts allow for the operating system and other supporting products to be patched without penalty. As a minimum identify what really can't change and what can.

So outside of those applications that are just too hard, implement a process that patches applications that can be patched, maybe remove those that are really not needed. For those applications that are to hard, you will have to find some other controls that help you reduce the risk to them, possibly strategy one?

Patch operating system vulnerabilities
Many organisations have this sorted reasonably well. A number of operating system provide a relatively robust process to update operating system components. One of the clients I work with does the following which works for them. When there is an advanced notification the bulletin is analysed. A determination is made whether the patch needs to be applied and how quickly. Once they are released they are implemented in the DEV environment straight away and systems are tested, assuming they do not break anything the patches are implemented in UAT and other non production environments. Systems are tested again (A standard testing process mostly automated). Production implementations are scheduled for a Sunday/Monday implementation. Assuming there are no issues stopping the implementation everything is patched by Monday morning. It takes effort, but with some automation the impact can be reduced. There are also a number of products on the market that will assist in the patching processes, simplifying life.

Minimise the number of users with domain or local administrative privileges.
Removing admin rights will also take a little bit of effort. Identify those that have administrative rights, domain or local. Identify what functions or roles they actually perform that require those full rights. Take local admin rights as an example. There are some applications that really do require the user to have local administrative rights. However there are also plenty that "need" them for the sake of convenience, rather than figuring out what access is really needed admin rights are given. Some applications you come across need admin right the first time they are run, after that no more. Your objective should be to remove all local admin rights from users and reduce domain administrative rights to as few as possible accounts in the environment.

You will need to test before implementing in production.

If it all seems overwhelming break it down into smaller jobs. Do those devices that are critical to the organisation first and then expand the efforts. But once done you will have reduced risk to the organisation and you can start looking at implementing the remaining 31 controls. As I said at the start not necessarily a standard, but how often can you say that you know of a way to reduce risk of targeted attacks by 85% or more?

I'm interested in finding out how you may have implemented one or more of the top 4 controls, please share by commenting, or let us know via the contact form and I'll add contributions later in the week.

Mark H - Shearwater

http://www.dsd.gov.au/infosec/top35mitigationstrategies.htm

Mark

391 Posts
ISC Handler

I was suprised to see that there was no explicit mention of disallowing default passwords. Perhaps it is covered by #27 "Enforce a strong passphrase policy", but not clearly.

T

31 Posts

Minimizing local and domain privileges is a big struggle, but has a big payoff. Our environment used to be really bad. All users were local admin and just about every member of IT was domain admin. Reading email as domain admin. *shudder*

First, we started with IT. We surveyed what each person in IT was doing and created access groups that would allow them to perform their job without Domain Admin. Help Desk was given rights to AD and other areas they needed without giving them full access. Same with devs and sys admins. Now they could use their regular login (sans Domain Admin) to perform 95% of their daily duties. For those in IT that required Domain Admin, we created a special account for them that allowed them to elevate when necessary. A few tweaks to permissions were necessary to get everything right, but it wasn't that hard. Most of the effort was around convincing everyone that they could still do their job without Domain Admin.

Next, we removed local admin from users. GPOs were used to enforce a list of user and groups in local admin, local power users, and local users. Most of our users went in a domain level "Power Users" group that was a member of the local Power Users group. Of course, there were applications that complained. We used Process Monitor to figure out where we were getting Access Denied errors. Then we would use a GPO to grant the needed folder permissions. It took a little work, but overall it went well. Of course, we also have a group we can put users in if they need local admin. But the IT manager must approve all additions to this group.

T
3 Posts