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.
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. 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? You will need to test before implementing in production. http://www.dsd.gov.au/infosec/top35mitigationstrategies.htm |
Mark 392 Posts ISC Handler Oct 30th 2012 |
Thread locked Subscribe |
Oct 30th 2012 9 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 |
Quote |
Oct 31st 2012 9 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 |
Quote |
Oct 31st 2012 9 years ago |
Sign Up for Free or Log In to start participating in the conversation!