ASD Top 4 Mitigation Strategies Maturity Model - Foresight · ASD Top 4 Mitigation Strategies...

foresightconsulting.com.au

ASD Top 4 Mitigation Strategies Maturity Model

ASD Top 4 Mitigation Strategies

Maturity Model 2

About Foresight Consulting Foresight Consulting provides information security consulting services across Australia, New Zealand and the South East Asian region, with our head office based in Canberra. We develop and implement security management solutions that are practical, robust and cost effective. Foresight Consulting has a strong background in the practical implementation of security solutions for Australian Government agencies and supporting organizations. For further information on our service offerings please see our website at www.foresightconsulting.com.au We appreciate any and all feedback. If you would like to provide comments or have a question about the maturity model please feel free to drop us a line at [email protected]

Acknowledgements Foresight would like to thank the Australian Signals Directorate for subject matter advice regarding their Top 4 Mitigation Strategies.

Licence

This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported Licence. To view a copy of this licence, visit http://creativecommons.org/licenses/by-sa/3.0/.

Disclaimer This document is for informational purposes only. Foresight IT Consulting Pty Ltd makes no warranties, express, implied, or statutory, as to the information in this document. This document is provided “as-is”. Information and views expressed within this document, including URL and other website references, may change without notice. You bear the risk of using it.

References

In the creation of the Top 4 Maturity Model Foresight reviewed a number of existing maturity models to determine the most appropriate and practical approach. As a result Foresight has leveraged OpenSAMM for the formatting of some components of our model.

Strategies to Mitigate Targeted Cyber Intrusions, ASD, February 2014

Australian Government Information Security Manual, ASD, March 2014

OpenSAMM, Pravir Chandra et al, v1.0

Assumptions

This document is primarily intended for a technical audience with an existing understanding of the ASD Top 4 Mitigation strategies.

http://www.foresightconsulting.com.au/

http://creativecommons.org/licenses/by-sa/3.0/


Maturity Model 3

Contents Executive Summary .................................................................................................. 4

Methodology ............................................................................................................. 5

Costs ......................................................................................................................... 7

#1 – Application Whitelisting ..................................................................................... 8

Overview ............................................................................................................... 8

Maturity Summary ................................................................................................ 8

#2 – Patch Applications .......................................................................................... 13

Overview ............................................................................................................. 13

Maturity Summary .............................................................................................. 13

#3 – Patch Operating System ................................................................................. 18

Overview ............................................................................................................. 18


#4 – Restrict Administrative Privileges .................................................................... 23

Overview ............................................................................................................. 23


Glossary .................................................................................................................. 28

Appendix A: Top 4 Maturity Model Calculator…………………………………...…….30


Maturity Model 4

Executive Summary Cyber security within Australian Government agencies has been a key focus over recent years. This is a direct reaction to a marked increase in the level of targeted intrusions being detected across government networks. In February 2010, the Australian Signals Directorate (ASD) formerly known as the Defence Signals Directorate (DSD) introduced the “Top 35 Strategies to Mitigate Targeted Cyber Intrusions”, a list of the most effective strategies to prevent compromise by persistent adversaries. As per the document: “the list is informed by ASD’s experience in operational cyber security, including responding to serious cyber incidents and performing vulnerability assessments and penetration testing for Australian Government agencies.”1

The list has been revised for 2012 and an increased focus has been placed on the Top 4 mitigation strategies:

1. Application whitelisting;

2. Patch applications;

3. Patch operating system;

4. Restrict administrative privileges.

“At least 85% of the intrusions that ASD responds to involve adversaries using unsophisticated techniques that would have been mitigated by implementing the Top 4 mitigation strategies as a package”2. There are a number of ways organisations are able to implement these strategies using various designs and technologies, however some prove to be more effective than others. As a result, many organisations implementing the Top 4 mitigation strategies don’t achieve a significant level of intrusion mitigation. The ASD Top 4 Mitigation Strategies – Maturity Model aims to address this problem and provide a framework which organisations can use to assess the effectiveness of their Top 4 implementation.

1 Australian Signals Directorate, Strategies to Mitigate Targeted Cyber Intrusions, Feb

2014, para 3. 2 Australian Signals Directorate, Strategies to Mitigate Targeted Cyber Intrusions, Feb

2014, para 5.


Maturity Model 5

Methodology Each mitigation strategy has been broken into four maturity levels. In order to achieve a significant level of intrusion mitigation, organisations must achieve an overall Top 4 effectiveness of ‘Resilient Organisation’. The chart below provides an overarching definition of these effectiveness levels:

Top 4 strategies have been

implemented effectively,

significantly mitigating

targeted cyber intrusion

techniques.

Resilient

Organisation

The Top 4 strategies

implementation is mature and

provides improved

security benefit.

Improved

Defence

Top 4 strategies have been

implemented with minimal

security benefit

Basic Security

Preparation to implement the

Top 4 mitigation strategies

Aware


Maturity Model 6

An organisations overall Top 4 effectiveness is determined by calculating a maturity score. This is done by applying the following mathematical formula to each strategies achieved maturity level (number):

(Strategy One x 2) + Strategy Two + Strategy Three + Strategy Four =

For example, if you achieved: Application whitelisting maturity level 2 Patch applications maturity level 1 Patch operating system maturity level 0 Restrict administrative privileges maturity level 1 The calculation would be (2 x 2) + 1 + 0 + 1 = 6 In this example an overall Top 4 effectiveness of ‘Basic Security’ has been achieved. Please see Appendix A for the interactive ‘Top 4 – Maturity Model Calculator’ (if this document is printed it will present a hard copy form). Each maturity level has a number of activities listed. Activities are core requisites for attaining a maturity level and are also pre-requisites for higher maturity levels. Organisations must complete and maintain the activities listed before progressing to the next maturity level.

Definitions of key terms used throughout this document can be found in the glossary.

Resilient Organisation - score 12 or more

Improved Defence - score between 9 - 11

Basic Security - score between 5 - 8

Aware - score 4 or less


Maturity Model 7

Costs Top 4 implementations vary in cost depending on the size of an organisation. In most Top 4 implementations, organisations are able to utilise existing technology platforms and require little to no additional financial investment. During the preparation of your Top 4 implementation, take the time to investigate any existing technology capabilities. The following technologies provide likely candidates for achieving each control: #1 Application Whitelisting: Many Anti-Virus products are capable and effective at performing Application Whitelisting and they are generally already installed on all endpoints. Software Restriction Policy (SRP) & Applocker are free in a modern Windows environment, however be aware of group policy limitations that prevent SRP & Applocker from effectively achieving the maturity level 3 activity of cryptographic hash blocking3.

#2 Patch Applications: Investigate how applications are currently deployed in the environment and if the mechanism is reliable and capable of rapid patch deployments. If no functionality exists many vendor patch solutions are available and WSUS is capable of providing this functionality for free.

#3 Patch Operating System: Investigate what operating systems are currently deployed in the environment and if they support a native patching mechanism that is reliable and capable of rapid patch deployments. WSUS is simple, effective and capable of performing these deployments in a Windows environment.

#4 Restrict Administrative Privileges: Enterprise account management systems are capable of restricting administrative privileges. Novell / Active Directory networks have this capability by default. Review the current configurations and capability of account management systems.

3 Group Policy is unable to store and process the large amount of hash values required for

cryptographic hash whitelisting to function effectively in an enterprise environment.


Maturity Model 8

#1 – Application Whitelisting Overview Application whitelisting is a pro-active security control. It prevents all software and associated libraries from running until an administrator has verified that it is trusted. This helps prevent malicious software from executing and requires manual verification of legitimate software. This is a different approach to traditional security and is necessary because anti-virus (blacklisting) is no longer an effective solution. In the modern day security environment, it is trivial for malware developers to evade signature based protection. Signature based protection is a reactive control, it picks up wide spread threats in the wild but not the targeted ones that are successfully compromising organisations. The importance of application whitelisting is reflected in ASD’s 2012 update of the top 35 mitigation strategies. Implemented effectively, application whitelisting is, by far, the most effective measure to detect and prevent targeted cyber intrusions.

Maturity Summary

Maturity Measure of Effectiveness

0 No application whitelisting is currently enabled.

1 Application whitelisting is enabled but is in ‘monitor mode’. Violations of policy are being centrally reported.

2 Application whitelisting is enabled and blocking. Policy has been configured to allow software to run based on parent folders i.e. all software in %programfiles% and %windir% can run. Executable files are denied execution outside of allowed parent folders by default. Logged on users are prevented write access to whitelisted folders and are unable to run executables in system directories that are typically only used for reconnaissance.

3 Application whitelisting is enabled and blocking. Policy has been configured to whitelist exclusively based on a file’s cryptographic hash. exe & dll files are denied execution by default if not on the approved cryptographic whitelist (regardless of folder location).


Maturity Model 9

#1 - Maturity Level 0

Activities

A. Identify Current Malware Risk / Information Value: Identify the current risk to your organisation from malware. Review previous intrusion incidents (if any) and note the intrusion vector used. Understand the value of the organisations information, where is the most sensitive data stored? What systems in the organisation provide access to this data? Conduct a threat risk assessment to determine the potential impact of a compromise to the organisation. Include the risks of information loss and reputation damage.

B. Choose an Application Whitelisting Technology: Determine what maturity level the organisation aims to achieve, not all application whitelisting technologies are capable of maturity level 3 (i.e. Software Restriction Policy (SRP) / Applocker). Investigate existing technologies that may be capable of application whitelisting. Determine if the anti-virus solution currently installed on your endpoints is capable. Make a decision based on demonstrated product capability in real world deployments.

Results

Understanding of

malware threat

‘Trophy information’ located and access determined

Technology choice made

Personnel

Security staff member

(5 days)

Architects (5 days)

Business Owners (1 day)

Managers (1 day)


Maturity Model 10


Activities

A. Enable Application Whitelisting ‘Observation Mode’: All application whitelisting technologies have an ‘observation mode’ which report on policy violations but do not enforce a block event. This mode assists in determining blocks that will occur before moving to maturity level 2 but will not provide any protection against malware. Fine tune policy in this mode.

B. Perform a Software Inventory ‘Observation mode’ will assist in determining what software is present on the network. Perform a software inventory and determine what software suites are business critical for the organization.

C. Centrally Log & Observe Policy Violations: ‘Observation mode’ is only useful if logs are being centrally reported to administrators. Most commercial solutions will automatically perform this. If you are using SRP & Applocker forward Event ID’s 865, 866, 867, 868 & 8000, 8003, 8004 using a log forwarder such as SNARE.

Results Application whitelisting

policy configured / tuning in progress

Software inventory performed

Policy violations centrally logged

Success Metrics >90% servers &

workstations are observing and centrally logging

Installing new applications triggers block events

Personnel Security staff (2 wk/yr)

Related Levels Patch Applications – 0


Maturity Model 11


Activities

A. Enable Application Whitelisting (Parent Folder Blocking): Application whitelisting must deny execution of all exe files outside of allowed folders. This must prevent the execution of all exe files inside all temp folders as a minimum. Whitelisted folders must not be writeable by logged on users. Blocks must centrally log. Blocks must be pro-active and observed upon installing new software into the environment. Users are unable to override blocks or disable application whitelisting.

B. Policy & Process Documentation must be created containing the following:

roles & responsibilities,

application whitelisting design,

troubleshooting guide, and

system management process.

C. Action Blocks, Malware & Policy Non-Compliance Logs generated must be actively monitored and blocks actioned appropriately. Non-compliance (such as administrators circumventing the control) must be addressed and actively prevented.

Results Moderate amounts of

malware pro-actively blocked

Attackers are limited in access

Greater visibility of software

Success Metrics >70% malware pro-

actively denied execution

>95% new software prevented from installing without a policy update


Support staff (1 wk/yr)


Restrict Administrative Privileges - 1


Maturity Model 12


Activities

A. Enable Application Whitelisting (Cryptographic Hash): Application whitelisting must deny execution of all dll & exe files regardless of folder location, unless contained on an allowed cryptographic hash list. Blocks must centrally log. Blocks must be pro-active and observed upon running any dll or exe’s in the environment. Users and administrators are unable to override blocks or disable application whitelisting.

B. Process to Capture Cryptographic Hashes In order to add cryptographic hashes to the whitelist, organisations should develop a process to efficiently capture known good file hashes. This can be performed by creating a ‘hash capture environment’. This environment contains a number of sandboxes where known good files can be analysed. These sandboxes monitor for system changes and capture the hash values of files when they are created or modified. Administrators are able to install, run & uninstall known good applications in these sandboxes to capture all the file hash values associated with a known good application.

C. Regular Control Testing The control should be regularly pen-tested to ensure it is working effectively. Policy gaps should be remediated.

Results Outstanding malware

defence

Malware unable to gain persistence

Efficient whitelist updates

• Success Metrics >99.9% malware pro-

actively denied execution

>99.9% of all new dll and exe files blocked from execution without a policy update

• Personnel Security staff (14 wk/yr)



Patch Operating System – 2

Restrict Administrative Privileges - 1


Maturity Model 13

#2 – Patch Applications Overview Patching applications is important for the security, stability and management of your operating environment. It removes known vulnerabilities from the environment commonly used in targeted intrusions. These vulnerabilities must be removed before an attacker has the opportunity to exploit them.

While it’s important to patch within 48 hours, the majority of the exploits being used are often between three months to three years old. It is important to apply the latest patches available, however it’s often more beneficial to update applications you have not touched in a few years.

Application patches undergo rigorous quality assurance and in the vast majority of cases do not require extensive testing before deployment in corporate environments.

Maturity Summary


0 No patching is currently being performed. Workstations / servers have application patches outstanding.

1 Patching is performed at random intervals on an undefined schedule. Workstations / servers have application patches outstanding. No vulnerability management program is currently in place. No patch management policy and process is currently in place.

2 Patching is performed in regular ‘rollup’ maintenance windows. Vulnerabilities are patched within 30 days of patch availability. Vulnerability management program is in place. Patch management policy and process is in place.

3 Patching is performed rapidly upon patch availability. Extreme risk* vulnerabilities are patched within 48 hours of release.

* “Extreme risk” vulnerabilities in software used by an organisation enable likely unauthorised code execution by an adversary using the Internet, that can result in significant consequences for the organisation.4

4 Defence Signals Directorate, Strategies to Mitigate Targeted Cyber Intrusions – Mitigation

Details, Oct 2012, section 12 para 2


Maturity Model 14


Activities

A. Perform a Software Inventory: Identify the software installed in your operating environment, including version and number of installations. Ensure that all highly targeted software is captured i.e. PDF viewers, Flash player, Microsoft Office, Java.

B. Create a Vulnerability Intelligence Feed: Ensure administrators are notified when vendors release patches. This can be done by subscribing to blogs, email notifications, twitter feeds & vulnerability intelligence companies. An example is the National Vulnerability Database RSS feed (http://nvd.nist.gov/download.cfm).

Results Software is identified

Organisation is notified when new vulnerabilities are published

Personnel Security staff (5 days)

Related Levels Application Whitelisting

– 1

Patch Operating Systems - 0

http://nvd.nist.gov/download.cfm

http://nvd.nist.gov/download.cfm


Maturity Model 15


Activities

A. Implement a Patch Deployment Solution: There are numerous effective patch deployment solutions on the market. Ensure the solution is not over engineered and is reliable at deploying patches (>90% of endpoint success).

B. Deploy Patches: Using the patch deployment solution apply patches to endpoints. At this maturity level patch application does not adhere to a particular schedule. Records of patching history must be kept and software inventories must be updated with new version details.

C. Track Patch Deployment: Ensure that patches are deploying successfully to endpoints and unsuccessful patch installations are remediated.

Results

Reliable patch deployment solution

Patches are being deployed

Success Metrics >90% endpoint patch

success

Vulnerabilities <1 year old

Personnel Administrator (4 wk/yr)

Managers (1 wk/yr)

Change board (1 wk/yr)



– 2,3


Maturity Model 16


Activities

A. Patch Management Policy & Process: Create a patch management policy and process containing the following: requirements, timeframes, testing, responsibilities, communication strategy and deployment. It is beneficial to have this policy contributed to and signed by all major stakeholders.

B. Vulnerability Management Program: Create a vulnerability management program. This program should provide patch notifications, co-ordinate patch pilots and deployments, test patches, assist in application and patch configuration, prioritise and schedule patching, harden applications to minimise vulnerabilities and scan / track vulnerabilities in the environment. In addition the program should include:

Security advisory / intelligence function,

Incident response plan, and

Ongoing vulnerability assessments.

C. Deploy & Pilot ‘Extreme Risk’ Patches <30 Days: Ensure that patches are applied successfully to workstations and servers within 30 days of patch release. Any unsuccessful patch installations must be remediated. Define a pilot group containing a cross section of users in the organisation, deploy to these users upon patch availability and gather feedback. This pilot group facilitates a rapid deployment of patches and will highlight any business critical issues within 24 hours through user reporting. If no issues are reported after this timeframe the patch deployment should be expanded.

Results

Vulnerability management policy & process defined.

Significant reduction in vulnerabilities

Success Metrics

Vulnerabilities <30 days old

Personnel Administrators (12 wk/yr)

Managers (2 wk/yr)



Related Levels

Application Whitelisting – 2,3


Maturity Model 17


5



Activities

A. Detailed Patch Management Policy & Process: Ensure the patch management policy and process maps vulnerability severities from vendors to deployment timeframes e.g. if a ‘critical’ Adobe patch is published and the organisation has no mitigating factors to decrease the risk, it must be applied within 48 hours as it is considered ‘extreme risk’.

B. Upgrade to the Latest Major Application Release: End-of-Life applications are not supported by the vendor.

Use the latest version of applications such as Adobe Reader X and later, which generally incorporate newer security technologies such as sandboxing. Avoid using:

Adobe Acrobat / Reader prior to version X,

Internet Explorer prior to version 8,

Microsoft Office prior to version 2010.

C. Deploy ‘Extreme Risk’ Patches <48 Hours: Ensure that patches are applied successfully to workstations and servers within 48 hours of patch release. Any unsuccessful patch installations must be remediated. Patches of all other severities (excluding low) must be applied within 30 days of release.

D. Quarterly Patch Level Reporting: Accurate patching levels must be reported to senior / executive management on a quarterly basis.

Results Up to date with

supported software

Very limited timeframe for vulnerability exploitation

Success Metrics N <1 Software Versions

Vulnerabilities <48 hours old


Managers (3 wk/yr)




– 2,3


Maturity Model 18

#3 – Patch Operating System Overview Patching operating systems is important for the security, stability and management of your operating environment. It removes known vulnerabilities commonly used for propagation and privilege escalation during targeted intrusions. These vulnerabilities must be removed before an attacker has the opportunity to exploit them. The majority of organisations today run one or two operating system platforms and in most instances they include native updating solutions which are provided free of charge. Operating system patches undergo rigorous quality assurance and in the vast majority of cases do not require extensive testing before deployment in corporate environments. For example, Microsoft deploys patches every month to over nine hundred million computers across the globe.

Maturity Summary


0 No patching is currently being performed. Workstations / servers have operating system patches outstanding.

1 Patching is performed at random intervals on an undefined schedule. Workstations / servers have operating system patches outstanding. No vulnerability management program is currently in place. No patch management policy and process is currently in place.

2 Patching is performed in regular ‘rollup’ maintenance windows. Vulnerabilities are patched within 30 days of patch availability. Vulnerability management program is in place. Patch management policy and process is in place.

3 Patching is performed rapidly upon patch availability. Extreme risk* vulnerabilities are patched within 48 hours of release.

* “Extreme risk” vulnerabilities in software used by an organisation enable likely unauthorised code execution by an adversary using the Internet, that can result in significant consequences for the organisation.6




Maturity Model 19


Activities

A. Perform an Operating System Inventory: Identify all operating systems running in your environment, including platform, version and number of installations. This can be performed via a manual audit or automated scanner.

B. Identify Current Patching Levels: Scan the identified operating systems to determine how many patches are missing. This can be performed using vulnerability scanners or patch management tools. An example is the Microsoft Baseline Security Analyser (MBSA) (http://technet.microsoft.com/en-us/security/cc184924.aspx). Patching levels should be recorded in a vulnerability database.

C. Create a Vulnerability Intelligence Feed: Ensure administrators are notified when vendors release patches. This can be done by subscribing to blogs, email notifications, twitter feeds & vulnerability intelligence companies. An example is the Microsoft Security Response Centre RSS feed (http://blogs.technet.com/b/msrc/rss.aspx).

Results Operating systems are

identified

Patching levels are known

Organisation is notified when new vulnerabilities are published

Personnel Security staff (5 days)

Architects (1 day)

Related Levels Patch Applications - 0

http://technet.microsoft.com/en-us/security/cc184924.aspx



http://blogs.technet.com/b/msrc/rss.aspx


Maturity Model 20


Activities

A. Implement a Patch Deployment Solution: There are numerous effective patch deployment solutions on the market. Ensure the solution is not over engineered and is reliable at deploying patches (>95% of endpoint success). Utilising the operating systems native updater is often the most simple and effective i.e. WSUS (http://technet.microsoft.com/en-us/windowsserver/bb332157.aspx).

B. Deploy Patches: Using the patch deployment solution apply patches to endpoints. At this maturity level patch application does not adhere to a particular schedule. Records of patching history must be kept and the vulnerability database must be updated with revised details.

C. Track Patch Deployment: Ensure that patches are deploying successfully to endpoints and unsuccessful patch installations are remediated.

Results Reliable patch

deployment

Occasional vulnerability reduction

Success Metrics >95% of operating

systems managed

>90% endpoint patch success

Vulnerabilities <1 year old


Architects (5 days)

Managers (1 wk/yr)


Support dtaff (1 wk/yr)


– 2,3

http://technet.microsoft.com/en-us/windowsserver/bb332157.aspx




Maturity Model 21


Activities

A. Patch Management Policy & Process: Create a patch management policy and process containing the following: requirements, timeframes, testing, responsibilities, communication strategy and deployment. It is beneficial to have this policy contributed to and signed by all major stakeholders.

B. Vulnerability Management Program: Create a vulnerability management program. This program should provide patch notifications, co-ordinate patch pilots and deployments, test patches, assist in operating system and patch configuration, prioritise and schedule patching, harden operating systems to minimise vulnerabilities and scan / track vulnerabilities in the environment.

C. Deploy & Pilot ‘Extreme Risk’ Patches <30 Days: Ensure that patches are applied successfully to workstations and servers within 30 days of patch release. Any unsuccessful patch installations must be remediated. Define a pilot group containing a cross section of users in the organisation, deploy to these users upon patch availability and gather feedback. This pilot group facilitates a rapid deployment of patches and will highlight any business critical issues within 24 hours through user reporting. If no issues are reported after this timeframe the patch deployment should be expanded.

Results Vulnerability

management policy & process defined

Significant reduction in vulnerabilities

Future patching time and effort is reduced as patching is performed in small controlled rollouts.

• Success Metrics Vulnerabilities <30 days

old


Managers (1 wk/yr)




– 2,3


Maturity Model 22


Activities

A. Detailed Patch Management Policy & Process: Ensure the patch management policy and process maps vulnerability severities from vendors to deployment timeframes e.g. if a ‘critical’ Microsoft patch is published and the organisation has no mitigating factors to decrease the risk, it must be applied within 48 hours as it is considered ‘extreme risk’.

B. Upgrade to an N <1 Operating System Release: Old operating systems such as Windows XP lack important security design principles to defend against modern threats. Upgrade to a N <1 operating system release to obtain additional security and stability benefits i.e. Address Space Layout Randomisation (ASLR) and User Account Control (UAC). End-Of-Life operating systems must not be used. Use 64bit operating systems where possible. Ensure compatibility testing is performed with in house applications.

C. Deploy ‘Extreme Risk’ Patches <48 Hours: Ensure extreme risk patches are applied successfully to workstations and servers within 48 hours of release. Any unsuccessful patch installations must be remediated. Patches of other severities (excluding low) must be applied within 30 days of release.

D. Quarterly Patch Level Reporting: Accurate patching levels must be reported to senior / executive management on a quarterly basis.

Results Modern operating

system implemented

Very limited timeframe for vulnerability exploitation

Success Metrics N <1 operating system

release

Vulnerabilities <48 hours old


Architects (2 wk/yr)

Managers (2 wk/yr)




– 2,3


Maturity Model 23

#4 – Restrict Administrative Privileges Overview Restricting administrative privileges in your environment is important to limit an attacker’s ability to execute code, propagate and exfiltrate information on your network. The majority of targeted intrusions involve a social engineering component where the user is tricked into opening a malicious file. In the majority of circumstances the attacker will gain the privileges of the user that opens this file. General users in an organisation are not often affected by restrictingg administrative privileges, as the majority of applications they need to perform their jobs can be run as a standard user.

Maturity Summary


0 Administrative privileges are prevalent in the environment. It is unknown how many accounts have administrative privileges or administrative access is provided by default.

1 Administrative privileges are governed by a standard account naming convention. Only essential administrative access is provided. Administrative functions are performed from standard workstations. Regular audits are performed to ensure legacy administrative access is revoked.

2 Administrators have been provided with a separate administrative account and have a primary standard login. Privileges are elevated when performing administrative functions.

3 Administrators perform administrative tasks from central management servers. Administrative accounts are blocked from accessing email and internet. Automated monitoring is performed to alert upon account modification.


Maturity Model 24


Activities

A. Perform an Account Audit: Identify how many accounts currently have administrative privileges and identify where in the organisation these accounts are used. Create a database containing usernames mapped to organisational units. Highlight which accounts have domain administrative privileges. Delete legacy accounts.

B. Identify Applications Requiring Administrative Access: Run all business critical (non-administrative) applications with a standard user account to determine if it is capable of running under minimised privileges. Contact the vendor for assistance if required.

C. Administrator Education: Ensure administrators are educated about why minimised privileges are important. Focus particularly on the concepts of privilege escalation, preventative measures such as User Account Control (UAC) and the dangers of opening emails and browsing the internet using administrative accounts.

Results Administrative accounts

identified

Incompatible software identified

Greater administrator awareness


Administrators (1 wk/yr)

Related Levels Patch Applications - 0


Maturity Model 25


Activities

A. Audit Administrative Access: Perform regular audits of administrative access to ensure the minimum level of access required is being provided. Implement solutions that reduce the need for administrative access for users e.g. an enterprise app store to allow on demand installation of managed applications.

B. Privileged Account Forms: When an administrator requires a privileged account they must sign a privileged account form agreeing to responsibilities associated with the access. This form should contain a business case of why the access is required and will assist when auditing administrative accounts.

C. Naming Convention Administrative accounts should be easily identifiable by name for management purposes, such as putting an _ or ! at the beginning of the account name.

D. Block administrative email and internet access: Administrative accounts must be blocked from accessing email and the internet from servers and workstations where possible.

Results Only essential

administrative access is provided

Account naming convention

Admin attack surface minimised

Success Metrics Reduction in

administrative access

Naming convention implemented

100% of administrative accounts blocked from email and internet


Architects (1 day/yr)



Maturity Model 26


Activities

A. Separate administrative accounts: Administrative accounts must be separated from standard user accounts. Everyone on the network including administrators use a standard account to log into their workstation and perform tasks that do not require administrative privileges. Upon commencement administrators are issued with a standard account and separate privileged account.

B. Privilege Elevation: Administrators must not log into a standard workstation with their administrative account and must instead elevate their privileges to a separate administrative account when administrative functions are required. This can be performed by running individual applications in administrative contexts (run as).

C. Remove email account associations: Administrative accounts must not have email accounts associated with them.

Results Limited threat exposure

to administrative accounts

Success Metrics 100% of administrative

accounts separated

100% of administrative accounts have no associated email address





Maturity Model 27


Activities

B. Create central management servers: Central management servers should be created to perform administrative functions from. This allows multiple administrators to remotely connect to the server and separate administrative functions from their standard desktop. Administrative management tools should be installed on this server.

C. Implement automated account monitoring: Automated monitoring should notify security staff when account modifications are made, in particular if a standard account has been given administrative privileges and domain administrative accounts are modified.

D. Administrative account use under change control (optional): Organisations may choose to permit the use of administrative accounts only under a change control. By default all administrative accounts will be disabled and temporarily enabled by security staff to perform a specific task outlined in the change control.

Results Administrative functions

performed separately / centrally

Automated monitoring in place

Success Metrics 95% of administration

performed from management servers





Maturity Model 28

Glossary Activities Activities are core requisites for attaining a maturity level and are also pre-requisites for higher maturity levels. Organisations must complete and maintain the activities listed before progressing to the next maturity level.

Personnel Personnel represents the estimated ongoing human resources overhead for the given maturity level.

Results Results are the outcomes obtained at each maturity level. These can be specifically defined or broadly stated as having an increased capability.

Success Metrics Success Metrics are examples to check if an organisation is performing at the given maturity level.

Related Levels Related Levels are references to maturity levels within other strategies that may potentially overlap or have pre-requisites. If the referenced maturity level is already in place it may assist or enhance implementation.

Application Whitelisting Application whitelisting is where a list of known good files are collected and given the ability to execute on a computer. Files not contained on this list are prevented from executing by default. This approach is proactive.

Application Blacklisting Application blacklisting is where a list of known bad files are collected and are prevented from executing on a computer. Anti-virus signatures are the most common example of an application blacklist. This approach is reactive.

Software Restriction Policy (SRP) SRP is a Microsoft Windows technology introduced in Windows XP SP2. It allows an administrator to control the execution of applications and provides a framework for basic application control using group policy rule sets.

Applocker Applocker is a Microsoft Windows technology introduced in Windows Vista. It expands on the capabilities of SRP and allows greater control over application execution, it provides an improved framework for application control using group policy rule sets.

Cryptographic Hash A Cryptographic hash is a fixed-length value which is calculated from an input (usually a file). This resulting hash value provides a fingerprint of the input which is unique in the vast majority of cases.

Vulnerability A Vulnerability is a weakness in a computer application or system.

Windows Server Update Services (WSUS) WSUS is a free technology provided by Microsoft to assist in patching operating systems and applications. It natively supports Microsoft products however can be used to deploy third party content.

User Account Control (UAC) UAC is a Microsoft Windows technology introduced in Windows Vista. UAC aims to reduce the use of administrative privileges in circumstances where they are not required, such as checking email or browsing the internet.


Maturity Model 29

Address Space Layout Randomisation (ASLR) ASLR is a security method which randomly arranges the positions of code in a computer’s memory. This makes exploiting a computer more complicated and less reliable. ASLR was first introduced in OpenBSD and is supported by Windows Vista and later operating systems.

N <1 Release An N <1 Release is the latest major software release minus one version behind. For example upgrading to an N <1 Microsoft Windows release would refer to ‘Windows 7’, as ‘Windows 8’ is currently the latest available.

Maturity Level

1 - Application Whitelisting

2 - Patch Applications

3 - Patch Operating System

4 - Restrict Administrative Privileges

Overall Top 4 Effectiveness

Dave

Typewritten Text

Dave

Typewritten Text

Dave

Typewritten Text

Dave

Typewritten Text

Dave

Sticky Note

Accepted set by Dave

Dave

Sticky Note

None set by Dave

Date post:	14-May-2018
Category:	Documents
Upload:	doankhue
View:	216 times
Download:	1 times

ASD Top 4 Mitigation Strategies Maturity Model - Foresight · ASD Top 4 Mitigation Strategies...

Documents